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Foreword 

This Technical Specification has been produced by the 3^^ Generation Partnership Project (3 GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. 
z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document defines the Stage 2 service description for the Evolved 3 GPP Packet Switched Domain - also 
known as the Evolved Packet System (EPS) in this document. The Evolved 3GPP Packet Switched Domain provides IP 
connectivity using the Evolved Universal Terrestrial Radio Access Network (E-UTRAN). 

The specification covers both roaming and non-roaming scenarios and covers all aspects, including mobility between E- 
UTRAN and pre-E-UTRAN 3 GPP radio access technologies, policy control and charging, and authentication. 

The Radio Access Network functionality is documented only to the extent necessary to describe the overall system. 
TS 36.300 [5] contains the overall description of the Evolved Universal Terrestrial Radio Access (E-UTRA) and 
Evolved Universal Terrestrial Radio Access Network (E-UTRAN). 

ITU-T Reconmiendation 1.130 [3] describes a three-stage method for characterisation of teleconmiunication services, 
and ITU-T Reconmiendation Q.65 [4] defines Stage 2 of the method. 

TS 23.402 [2] is a companion specification to this specification. 



2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3 GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 



[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 23.402: "Architecture enhancements for non-3GPP accesses". 

[3] ITU-T Recommendation 1.130: "Method for the characterization of telecommunication services 

supported by an ISDN and network capabilities of an ISDN". 

[4] ITU-T Recommendation Q.65: "The unified functional methodology for the characterization of 

services and network capabilities". 

[5] 3GPP TS 36.300: "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal 

Terrestrial Radio Access (E-UTRAN); Overall description; Stage 2". 

[6] 3GPP TS 23.203: "PoHcy and charging control architecture". 

[7] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2". 

[8] 3GPP TS 43.129: "Packet-switched handover for GERAN A/Gb mode; Stage 2". 

[9] 3GPP TS 23.003: "Numbering, addressing and identification". 

[10] 3GPP TS 23.122: "Non- Access-Stratum (NAS) functions related to Mobile Station in idle mode". 

[II] 3GPP TS 43.022: "Functions related to MS in idle mode and group receive mode". 

[12] 3GPP TS 25.304: "UE procedures in idle mode and procedures for cell re-selection in connected 

mode". 

[13] 3GPP TS 23.246: "Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional 

description". 
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[14] 3GPP TS 29.060: "GPRS Tunnelling Protocol (OTP) across the Gn and Gp interface". 

[15] 3GPP TS 43.051: "GERAN Overall description - Stage 2". 

[16] 3GPP TS 25.401 : "UTRAN overall description". 

[17] IETF RFC 1034 (1987): "Domain names - concepts and facilities" (STD 13). 

[18] IETF RFC 4862: "IPv6 Stateless Address Autoconfiguration". 

[19] IETF RFC 2131: "Dynamic Host Configuration Protocol". 

[20] IETF RFC 3736: "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6". 

[21] IETF RFC 3633: "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 

6". 

[22] 3GPP TS 25.413: "UTRAN lu interface Radio Access Network Application Part (RANAP) 

signalling". 

[23] 3GPP TS 44.064: "Mobile Station - Serving GPRS Support Node (MS-SGSN); Logical Link 

Control (LLC) Layer Specification". 

[24] 3GPP TS 23.251: "Network Sharing; Architecture and functional description". 

[25] IETF RFC 4039: "Rapid Conmiit Option for the Dynamic Host Configuration Protocol version 4 

(DHCPv4)". 

[26] IETF RFC 768 : "User Datagram Protocol" . 

[27] 3GPP TS 23.221 : "Architectural requirements". 

[28] 3GPP TS 23.008: "Organization of subscriber data". 

[29] 3GPP TS 23.078: "Customized AppHcations for Mobile network Enhanced Logic (CAMEL) Phase 

X; Stage 2". 

[30] 3GPP TS 23.236: "Intra-domain connection of Radio Access Network (RAN) nodes to multiple 

Core Network (CN) nodes". 

[31] IETF RFC 3588: "Diameter Base Protocol". 

[32] IETF RFC 486 1 : "Neighbor Discovery for IP Version 6 (IPv6)" . 

[33] 3GPP TS 25.331: "Radio Resource Control (RRC); Protocol Specification". 

[34] 3GPP TS 36.304: "Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) 

procedures in idle mode". 

[35] IETF RFC 2960: "Stream Control Transmission Protocol". 

[36] 3GPP TS 36.413: "Evolved Universal Terrestrial Access Network (E-UTRAN); SI Apphcation 

Protocol (SlAP)". 

[37] 3GPP TS 36.33 1 : "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource 

Control (RRC); Protocol specification". 

[38] 3GPP TS 29.061 : "Interworking between the PubHc Land Mobile Network (PLMN) supporting 

packet based services and Packet Data Networks (PDN)". 

[39] IETF RFC 3041: "Privacy Extensions for Stateless Address Autoconfiguration in IPv6". 

[40] 3GPP TS 33.102: "3G Security; Security architecture". 

[41] 3GPP TS 33.401 : "3GPP System Architecture Evolution: Security Architecture". 

[42] 3GPP TS 48.018: "General Packet Radio Service (GPRS); Base Station System (BSS) - Serving 

GPRS Support Node (SGSN); BSS GPRS Protocol (BSSGP)". 
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[43] 3GPP TS 29.274: "General Packet Radio Service (GPRS); Evolved GPRS Tunnelling Protocol 

(eGTP)for EPS". 

[44] 3GPP TS 32.251: "Telecommunication management; Charging management; Packet Switched 

(PS) domain charging". 

[45] 3GPP TS 24.007: "Mobile radio interface signalHng layer 3; General aspects". 

[46] 3GPP TS 24.301 : "Non- Access-Stratum (NAS) protocol for Evolved Packet System (EPS); 

Stage 3". 

[47] 3GPP TS 24.008: "Mobile Radio Interface Layer 3 specification; Core Network Protocols; 

Stage 3". 

3 Definitions and abbreviations 
3.1 Definitions 



For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1]. 

MME Pool Area: An MME Pool Area is defined as an area within which a UE may be served without need to change 
the serving MME. An MME Pool Area is served by one or more MMEs ("pool of MMEs") in parallel. MME Pool 
Areas are a collection of complete Tracking Areas. MME Pool Areas may overlap each other. 

Serving GW Service Area: A Serving GW Service Area is defined as an area within which a UE may be served 
without need to change the Serving GW. A Serving GW Service Area is served by one or more Serving GWs in 
parallel. Serving GW Service Areas are a collection of complete Tracking Areas. Serving GW Service Areas may 
overlap each other. 

PDN Connection: The association between a UE represented by one IPv4 address and/or one IPv6 prefix/address, and 
a PDN represented by an APN. 

Default APN: A Default APN is defined as the APN which is marked as default in the subscription data and used 
during the Attach procedure for PDN connection. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [1]. 



AMBR 


Aggregate Maximum Bit Rate 


DL TFT 


DownLink Traffic Flow Template 


ECGI 


Evolved Cell Global Identifier 


ECM 


EPS Connection Management 


EMM 


EPS Mobility Management 


EPC 


Evolved Packet Core 


EPS 


Evolved Packet System 


GUMMEI 


Globally Unique MME Identifier 


GUTI 


Globally Unique Temporary Identity 


GW 


Gateway 


PDB 


Packet Delay Budget 


PER 


Packet Loss Rate 


LBI 


Linked EPS Bearer Id 


MME 


Mobility Management Entity 


MMEC 


MME Code 


M-TMSI 


M-Temporary Mobile Subscriber Identity 


P-GW 


PDN Gateway 


PTI 


Protocol Transaction Id 
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S-GW 


Serving Gateway 


S-TMSI 


S-Temporary Mobile Subscriber Identity 


SDF 


Service Data Flow 


TAG 


Tracking Area Gode 


TAI 


Tracking Area Identity 


TAU 


Tracking Area Update 


TIN 


Temporary Identity used in Next update 


UL TFT 


UpLink Traffic Flow Template 



4 Architecture model and concepts 

4.1 General concepts 

Local breakout of IP traffic via the visited PLMN is supported, when network policies and user subscription allow it. 
Local breakout may be combined with support for multiple simultaneous PDN connections, described in clause 5.10. 

4.2 Architecture reference model 
4.2.1 Non-roaming architecture 
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Figure 4.2.1-1 : Non-roaming architecture for 3GPP accesses 
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Figure 4.2.1-2: Non-roaming architecture for 3GPP accesses. Single gateway configuration option 

NOTE 1: Also in this configuration option, S5 can be used between non collocated Serving Gateway and PDN 
Gateway. 

NOTE 2: Additional interfaces for 2G/3G access are shown in TS 23.060 [7]. 
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Figure 4.2.2-1 : Roaming architecture for 3GPP accesses. Home routed traffic 

NOTE 1: Additional interfaces/reference points for 2G/3G accesses are documented in TS 23.060 [7]. 

The figures 4.2.2-2 and 4.2.2-3 represent the Roaming with local breakout case with Application Function (AF) in the 
Home Network and in the Visited Network respectively. The concurrent use of AF's in the home network and AF's in 
the visited network is not excluded. 
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Figure 4.2.2-2: Roaming architecture for local breakout, with home operator's application functions 

only 

NOTE 2: See TS 23.203 [6 ] for the role of and functions related to Home and Visited PCRF and S9/Rx reference 
points. 

NOTE 3: In figure 4.2.2-2, the control plane signaling and the user plane for accessing to Home Operator's services 
traverse over the SGi reference point via the Visited Operator's PDN. 
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Figure 4.2.2-3: Roaming architecture for local breakout, with visited operator's application functions 

only 



4.3 High level functions 

4.3.1 General 

The following list gives the logical functions performed within this system. Several functional groupings (meta 
functions) are defined and each encompasses a number of individual functions: 

- Network Access Control Functions. 

- Packet Routeing and Transfer Functions. 

- Mobility Management Functions. 

- Security Functions. 

- Radio Resource Management Functions. 

- Network Management Functions. 

4.3.2 Network access control functions 

4.3.2.1 General 

Network access is the means by which a user is connected to the evolved packet core system. 

4.3.2.2 Network/Access network selection 

It is the means by which a UE selects a PLMN/ Access network from which to gain IP connectivity. The network/access 
network selection procedure varies for different access technologies. For 3GPP access networks, the network selection 
principles are described in TS 23.122 [10]. For 3GPP access networks, the access network selection procedures are 
described in TS 36.300 [5], TS 43.022 [11] and TS 25.304 [12]. 
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Architectural impacts stemming from support for network/access network selection procedures for non-3 GPP access 
and between 3GPP access and non-3GPP accesses are described in TS 23.402 [2]. 

4.3.2.3 Authentication and authorisation function 

This function performs the identification and authentication of the service requester, and the validation of the service 
request type to ensure that the user is authorised to use the particular network services. The authentication function is 
performed in association with the Mobility Management functions. 

4.3.2.4 Admission control function 

The purpose of admission control is to determine if the requested resources are available, and then reserve those 
resources. 

4.3.2.5 Policy and Charging Enforcement Function 

This includes all the functionality of PCEF as defined by TS 23.203 [6]. The PCEF encompasses service data flow 
detection, policy enforcement and flow based charging functionalities as defined in TS 23.203 [6]. 

4.3.2.6 Lawful Interception 

Lawful interception is the action, performed by a network operator / access provider / service provider, of making 
available certain information and providing that information to a law enforcement monitoring facility. 

4.3.3 Packet routeing and transfer functions 

4.3.3.1 General 

A route is an ordered list of nodes used for the transfer of packets within and between the PLMN(s). Each route consists 
of the originating node, zero or more relay nodes and the destination node. Routeing is the process of determining and 
using, in accordance with a set of rules, the route for transmission of a message within and between the PLMN(s). 

The EPS is an IP network and uses the standard routeing and transport mechanism of underlying IP network. 

Editor's note: The above text does not appear to be relevant to a functional description. 

4.3.3.2 IP header compression function 

The IP header compression function optimises use of radio capacity by IP header compression mechanisms. 

4.3.3.3 Packet screening function 

The packet screening function provides the network with the capability to check that the UE is using the exact IPv4- 
Address/IPv6-Prefix/Full-IPv6-Address that was assigned to the UE. 

4.3.4 Security functions 

4.3.4.1 Ciphering function 

The ciphering function preserves the confidentiality of user data and signalling across the radio channels. 

4.3.4.2 Integrity protection function 

The integrity protection function ensures the integrity of the signalling between the UE and the network. 
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4.3.5 Mobility management functions 

4.3.5.1 General 

The mobility management functions are used to keep track of the current location of a UE. 

4.3.5.2 Reachability Management for UE in ECM-IDLE state 

The location of a UE in ECM-IDLE state is known by the network on a Tracking Area List granularity. A UE in ECM- 
IDLE state is paged in all cells of the Tracking Areas in which it is currently registered. The UE may be registered in 
multiple Tracking Areas. 

A UE performs periodic Tracking Area Updates with the network after the expiry of the periodic TAU timer. 

If the UE is out of E-UTRAN coverage (including the cases when the UE is camped on 2G/3G cells) when its periodic 
TAU update timer expires, then the UE should perform a Tracking Area Update when it next returns to E-UTRAN 
coverage. If the UE is camped on an E-UTRAN cell or is in ECM-CONNECTED state when the UE's periodic RAU or 
periodic LAU timer expires, the UE should perform a Routeing Area Update to the SGSN or a Location Area Update to 
the MSC when it next returns to 2G/3G coverage. 

Expiry of the periodic TAU timer, or, the periodic RAU timer, or, the periodic LAU timer shall not cause the UE to 
change RAT. 

The UE's periodic TAU timer is restarted from its initial value whenever the UE enters ECM-IDLE mode and when the 
UE leaves the E-UTRAN connection due to handover. UTRAN RRC state transitions and 2G GPRS 
STANDBY/READY state transitions shall have no other impact on the periodic TAU timer. 

E-UTRAN RRC state transitions shall have no impact on the periodic RAU timer or periodic LAU timer except that 
handover from 2G/3G to E-UTRAN shall cause the periodic RAU timer to be started from its initial value. 

Typically, the MME runs a timer with a similar value to the UE's periodic TAU timer. If this timer expires in the MME, 
the MME can deduce that the UE is 'out of coverage' at that moment. However, the MME does not know for how long 
the UE has been out of coverage, so, the MME shall not immediately delete the UE's bearers. Instead the MME should 
clear the PPF flag in the MME and start a second timer, with a relatively large value. With the PPF clear, the MME 
does not page the UE in EUTRAN coverage and shall send a Downlink Data Notification Reject message to the Serving 
GW when receiving a Downlink Data Notification message from the Serving GW. If this second timer expires before 
the UE contacts the network, then the MME can deduce that the UE has been 'out of coverage' for a long period of time: 

In the case of Idle Mode Signalling Reduction being active for the UE, after the second timer expires, the MME 
shall set its "Implicit detach permitted" flag. Any time after both MME and SGSN have set their "Implicit detach 
permitted" flags, the MME and SGSN impHcitly detach the UE. If the UE enters ECM-CONNECTED mode, the 
MME shall clear the "Implicit detach permitted" flag and set the PPF flag. 

NOTE 1: If ISR is active, the SGSN has similar functionality. 

- In case of Idle Mode Signalling Reduction is not activated for the UE, any time after the second timer expires, 
the MME implicitly detach the UE. 

NOTE 2: Alternative MME implementations are permitted, however, the externally visible MME behaviour should 
conform to the above description. 

4.3.5.3 Tracking Area list management 

Tracking Area list management comprises the functions to allocate and reallocate a Tracking Area Identity list to the 
UE. 

4.3.5.4 Inter-eNodeB mobility anchor function 

The Inter-eNodeB Mobility Anchor is the functional entity that anchors the user plane for E-UTRAN mobility. 
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4.3.5.5 lnter-3GPP mobility anchor function 

The Inter-3GPP Mobility Anchor is the functional entity that anchors the user plane for mobility between 3GPP 2G/3G 
access systems and the E-UTRA access system. 

4.3.5.6 Idle mode signalling reduction function 

The Idle mode Signalling Reduction function provides a mechanism to limit signalling during inter-RAT cell- 
reselection in idle mode (ECM-IDLE, PMM-IDLE, GPRS STANDBY states). 

4.3.5.7 Mobility Restrictions 

Mobility Restrictions comprises the functions for restrictions to mobility handling of a UE in E-UTRAN access. The 
Mobility Restriction functionality is provided by the UE, the radio access network and the core network. 

Mobility Restriction functionality in state ECM-IDLE is executed in UE based on information received from the core 
network. Mobility Restriction functionality in state ECM-CONNECTED is executed in the radio network and the core 
network. 

In state ECM-CONNECTED, the core network provides the radio network with a Handover Restriction List. The 
Handover Restriction List specifies roaming, area and access restrictions. 

4.3.6 Radio Resource Management functions 

Radio resource management functions are concerned with the allocation and maintenance of radio communication 
paths, and are performed by the radio access network. 

To support radio resource management in E-UTRAN the MME provides the parameter 'RAT/Frequency Selection 
Priority' (RFSP) to an eNB across SL The RFSP is a 'per UE' parameter that is used by the E-UTRAN to derive UE 
specific cell reselection priorities to control idle mode camping. The RFSP may also be used by the E UTRAN to decide 
on redirecting active mode UEs to different frequency layers or RATs. 

The MME receives the RFSP from the HSS (e.g., during the Attach procedure). For non-roaming subscribers the MME 
transparently forwards the RFSP to the eNB across S 1 . For roaming subscribers the MME may alternatively send an 
RFSP value to the eNB across SI that is based on the visited network policy (e.g., an RFSP pre-configured per 
HPLMN, or a single RFSP values to be used for all roamers independent of the HPLMN). 

Refer to TS 36.300 [5] for further information on E-UTRAN. 

4.3.7 Network management functions 

4.3.7.1 General 

Network management functions provide mechanisms to support O&M functions related to the Evolved System. 

The Network management architecture and functions for the evolved packet core system are described in TS ss.xyz [qq] 

4.3.7.2 Load balancing between MMEs 

The MME Load Balancing functionality permits UEs that are entering into an MME Pool Area to be directed to an 
appropriate MME in a manner that achieves load balancing between MMEs. This is achieved by setting a Weight Factor 
for each MME, such that the probability of the eNodeB selecting an MME is proportional to its Weight Factor. The 
Weight Factor is typically set according to the capacity of an MME node relative to other MME nodes. 

Editor's Note: It is FES how the Weight Factor is provided to the eNodeB. 

NOTE 1: An operator may decide to change the Weight Factor after the establishment of SI -MME connectivity as 
a result of changes in the MME capacities. E.g., a newly installed MME may be given a very much higher 
weight for an initial period of time making it faster to increase its load. 
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NOTE 2: It is intended that the Weight Factor is NOT changed frequently, e.g. in a mature network, changes on a 
monthly basis could be anticipated, e.g. due to the addition of RAN or CN nodes. 



The MME Load Re-balancing functionality permits UEs that are registered on an MME (within an MME Pool Area) to 
be moved to another MME. 

NOTE 1 : An example use for the MME Load Re-balancing function is for the 0+M related removal of one MME 
from an MME Pool Area. 

NOTE 2: Typically, this procedure should not be used when the MME becomes overloaded because the Load 

Balancing function should have ensured that the other MMEs in the pool area are similarly overloaded. 

The eNodeBs may have their Load Balancing parameters adjusted beforehand (e.g. the Weight factor is set to zero if all 
subscribers are to be removed from the MME, which will route new entrant to the pool area into other MMEs). 

The MME should off-load a cross section of its subscribers with minimal impacts on the network and users (e.g. the 
MME should avoid offloading only the low activity users while retaining the high activity subscribers. Gradual rather 
than sudden off-loading should be performed as a sudden re-balance of large number of subscribers could overload 
other MMEs in the pool.With minimal impact on network and the user's experience, the subscribers should be off- 
loaded as soon as possible). The load re-balancing can off-load part of or all the subscribers. 

To off-load ECM-CONNECTED mode UEs for which there is no TAU, Attach, Detach or Service request procedure in 
progress, the inter eNodeB handover with MME relocation procedure (clause 5.5.1.2) is used with the source eNodeB 
being identical to the target eNodeB. The procedure is triggered by the MME sending a Handover Trigger message to 
the eNodeB to move a particular UE. 

Editor's note: It is FES whether other means of triggering handover need to be specified. 

To off-load UEs who perform TA Updates or Attachs, it is FES which mechanism is used to allow eNodeB to determine 
it has to transfer the UE to a new MME. 

Editor's note: The following mechanisms have been proposed: 

(1) The MME receives the Tracking Area Update request or Attach request and returns an indication in 
the accept message and releases the S 1 connection. After receiving the indication, the UE will initiate a 



new TAU procedure with a new MME reselection indication in RRC part. 

(2) The MME receives the Tracking Area Update or Attach request and retrns a Redirection indication 
(including the NAS part) to the eNodeB. After receiving the indication, the eNodeB forwards NAS 
message to a newly selected MME. 

(3) The MME informs the eNodeB to move all subsequent TAU Request or Attach to a new MME node. 
In all secenarios, the eNodeB will treat the UE "as a new entrant to the pool area" and select another 
MME according to clause 4.3.8.3 on "MME selection function". The new MME will retrieve UE context 
from the old MME. 



To off-load UEs in ECM-IDLE state without waiting for the UE to perform a TAU or perform Service request and 
become ECM-CONNECTED, the MME first pages UE to bring it to ECM-CONNECTED state. 



The MME shall contain mechanisms for handling overload situations. These can include the use of NAS signalling to 
reject NAS requests from UEs. 

In addition, under unusual circumstances, the MME may need to restrict the load that its eNodeBs are generating on it. 
This can be achieved by the MME invoking the SI interface overload procedure (see TS 36.300 [5] and TS 36.413 [36] 
to a proportion of the eNodeB 's with which the MME has SI interface connections. To reflect the amount of load that 
the MME wishes to reduce, the MME can adjust the proportion of eNodeBs which are sent SI interface OVERLOAD 
START message, and the content of the OVERLOAD START message. 

The MME should select the eNodeBs at random (so that if two MMEs within a pool area are overloaded, they do not 
both send OVERLOAD START messages to exactly the same set of eNodeBs). 

Using the OVERLOAD START message, the MME can, for example, request the eNodeB to: 



4.3.7.3 



Load re-balancing between MMEs 



4.3.7.4 



MME control of overload 
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- reject all non-emergency Service Request messages for that MME; and/or 

- reject all Service Request messages that are response to paging for that MME; and/or 

- reject all new RRC connections for EPS Mobility Management signalling (e.g. for TA Updates) for that MME; 
and/or 

- only permit RRC connection establishments for emergency sessions for that MME. 

NOTE: The support for emergency sessions (and subsequent support within priority services) are not fully 
supported in this release. 

When the MME has recovered and wishes to increase its load, the MME sends OVERLOAD STOP messages to the 
eNodeB(s). 

Hardware and/or software failures within an MME may reduce the MME's load handling capability. Typically such 
failures should result in alarms which alert the operator/O+M system. Only if the operator/O+M system is sure that 
there is spare capacity in the rest of the pool, the operator/O+M system might use the load re-balancing procedure to 
move some load off this MME. However, extreme care is needed to ensure that this load re-balancing does not overload 
other MMEs within the pool area (or neighbouring SGSNs) as this might lead to a much wider system failure. 

4.3.8 Selection functions 

4.3.8.1 PDN GW selection function (3GPP accesses) 

The PDN GW selection function allocates a PDN GW that shall provide the PDN connectivity for the 3GPP access. The 
function uses subscriber information provided by the HSS and possibly additional criteria. For each of the subscribed 
PDNs, the HSS provides one or more PDN subscription contexts each containing: 

- the identity of a PDN GW and an APN (PDN subscription contexts with subscribed PDN GW address are not 
used when there is interoperation with pre Rel-8 2G/3G SGSN), or 

an APN and an indication for this APN whether the allocation of a PDN GW from the visited PLMN is allowed 
or whether a PDN GW from the home PLMN shall be allocated. Optionally an IP address of a PDN GW may be 
contained for handover with non-3GPP accesses. 

In the case of static address allocation, a static PDN GW is selected by either having the APN configured to map to a 
given PDN GW, or the PDN GW identity provided by the HSS indicates the static PDN GW. 

The HSS also indicates which of the PDN subscription contexts is the Default one for the UE. 

To establish connectivity with a PDN when the UE is already connected to one or more PDNs, the UE provides the 
requested APN for the PDN GW selection function. 

If the HSS provides the identity of a PDN GW, no further PDN GW selection functionality is performed. The PDN GW 
identity refers to a specific PDN GW. If the PDN GW identity includes the IP address of the PDN GW, that IP address 
shall be used as the PDN GW IP address; otherwise the PDN GW identity includes an FQDN which is used to derive 
the PDN GW IP address by using Domaind Name Service function, taking into account the protocol type on S5/S8 
(PMIP or GTP). 

NOTE: Provision of a PDN GW identity of a PDN GW as part of the subscriber information allows also for a 
PDN GW allocation by HSS. 

If the HSS provides a PDN subscription context that allows for allocation of a PDN GW from the visited PLMN for this 
APN, the PDN GW selection function derives a PDN GW identity from the visited PLMN. If a visited PDN GW 
identity cannot be derived, or if the subscription does not allow for allocation of a PDN GW from the visited PLMN, 
then the APN is used to derive a PDN GW identity from the HPLMN. The PDN GW identity is derived from the APN, 
subscription data and additional information by using the Domain Name Service function. If the PDN GW identity is a 
logical name instead of an IP address, the PDN GW address is derived from the PDN GW identity, protocol type on 
S5/S8 (PMIP or GTP) by using the Domain Name Service function. The SB protocol type (PMIP or GTP) is configured 
per HPLMN in MME/SGSN. 

If the APN-OI Replacement field exists in the subscription data, the PDN GW domain name will be constructed by 
replacing the APN-OI with the value received in the APN-OI Replacement field. Otherwise, or when the resolution of 
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the above PDN GW domain name fails, the PDN GW domain name will be constructed by appending 
'.mnc<MNC>.mcc<MCC>.gprs' as specified in Annex A of TS 23.060 [7] and TS 23.003 [9]. If the Domain Name 
Service function provides a list of PDN GW addresses, one PDN GW address is selected from this list. If the selected 
PDN GW cannot be used, e.g. due to an error, then another PDN GW is selected from the list. 

If the UE provides an APN for a PDN, this APN is then used to derive the PDN GW identity as specified for the case of 
HSS provided APN if one of the subscription contexts allows for this APN. 

If there is an existing PDN connection to the same APN used to derive the PDN GW address, the same PDN GW shall 
be selected. 

As part of PDN GW selection, an IP address of the assigned PDN GW may be provided to the UE for use with host 
based mobility as defined in TS 23.402 [2], if the PDN GW supports host-based mobility for inter-access mobility 
towards accesses where host-based mobility can be used. If a UE explicity requests the address of the PDN GW and the 
PDN GW supports host based mobility then the PDN GW address shall be returned to the UE. 

4.3.8.2 Serving GW selection function 

The Serving GW selection function selects an available Serving GW to serve a UE. The selection bases on network 
topology, i.e. the selected Serving GW serves the UE's location and in case of overlapping Serving GW service areas, 
the selection may prefer Serving GWs with service areas that reduce the probability of changing the Serving GW. Other 
criteria for Serving GW selection should include load balancing between Serving GWs. 

If a subscriber of a GTP only network roams into a PMIP network, the PDN GWs selected for local breakout support 
the PMIP protocol, while PDN GWs for home routed traffic use GTP. This means the Serving GW selected for such 
subscribers may need to support both GTP and PMIP, so that it is possible to set up both local breakout and home 
routed sessions for these subscribers. For a Serving GW supporting both GTP and PMIP, the MME/SGSN should 
indicate the Serving GW which protocol should be used over S5/S8 interface. The MME/SGSN is configured with the 
S8 variant(s) on a per HPLMN granularity. 

If a subscriber of a GTP only network roams into a PMIP network, the PDN GWs selected for local breakout may 
support GTP or the subscriber may not be allowed to use PDN GWs of the visited network. In both cases a GTP only 
based Serving GW may be selected. These cases are considered as roaming between GTP based operators. 

If combined Serving and PDN GWs are configured in the network the Serving GW Selection Function preferably 
derives a Serving GW that is also a PDN GW for the UE. 

The Domain Name Service function may be used to resolve a DNS string into a list of possible Serving GW addresses 
which serve the UE's location. The details of the selection are implementation specific. 

For handover from non-3GPP accesses in roaming scenario, the Serving GW selection function for local anchoring is 
described in TS 23.402 [2]. 

4.3.8.3 MME selection function 

The MME selection function selects an available MME for serving a UE. The selection is based on network topology, 
i.e. the selected MME serves the UE's location and in case of overlapping MME service areas, the selection may prefer 
MMEs with service areas that reduce the probability of changing the MME. When an eNodeB selects an MME, the 
selection shall achieve load balancing as specified in clause 4.3.6.2. 

4.3.8.4 SGSN selection function 

The SGSN selection function selects an available SGSN to serve a UE. The selection is based on network topology, i.e. 
the selected SGSN serves the UE's location and in case of overlapping SGSN service areas, the selection may prefer 
SGSNs with service areas that reduce the probability of changing the SGSN. Other criteria for SGSN selection may be 
load balancing between SGSNs. 

4.3.8.5 Selection of PCRF 

The PDN-GW and AF may be served by one or more PCRF nodes in the HPLMN and, in roaming with local breakout 
scenarios, one or more PCRF nodes in the VPLMN. 
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The selection of PCRF and linking of the different UE's PCC sessions over the multiple PCRF interfaces (e.g. Rx 
session, Gx session, S9 session etc.) for a UE IP CAN session is described in TS 23.203 [6]. 

4.3.9 IP network related functions 

4.3.9.1 Domain Name Service function 

The Domain Name Service function resolves logical PDN GW names to PDN GW addresses. This function is standard 
Internet functionality according to RFC 1034 [17], which allows resolution of any name to an IP address (or addresses) 
for PDN GWs and other nodes within the EPS. 

4.3.9.2 DHCP function 

The Dynamic Host Configuration Function allows to deliver IP configuration information for UEs. This function is 
standard Internet functionality according to RFC 2131 [19], RFC 3736 [20], RFC 3633 [21] and RFC 4039 [25]. 

4.3.10 Functionality for Connection of eNodeBs to Multiple MMEs 

An eNodeB may connect to several MMEs. This implies that an eNodeB must be able to determine which of the 
MMEs, covering the area where an UE is located, should receive the signalling sent from a UE. To avoid unnecessary 
signalling in the core network, a UE that has attached to one MME should generally continue to be served by this MME 
as long as the UE is in the radio coverage of the pool area to which the MME is associated. The concept of pool area is 
a RAN based definition that comprises one or more TA(s) that, from a RAN perspective, are served by a certain group 
of MMEs. This does not exclude that one or more of the MMEs in this group serve TAs outside the pool area. This 
group of MMEs is also referred to as an MME pool. 

To enable the eNodeB to determine which MME to select when forwarding messages from an UE, this functionality 
defines a routing mechanism (and other related mechanism). A routing mechanism (and other related mechanism) is 
defined for the MMEs. The routing mechanism is required to find the correct old MME (from the multiple MMEs that 
are associated with a pool area). When a UE roams out of the pool area and into the area of one or more MMEs that do 
not know about the internal structure of the pool area where the UE roamed from, the new MME will send the 
Identification Request message or the Context Request message to the old MME using the GUTI. The routing 
mechanism in both the MMEs and the eNodeB utilises the fact that every MME that serves a pool area must have its 
own unique value range of the GUTI parameter within the pool area. 

4.4 Network elements 

4.4.1 E-UTRAN 

E-UTRAN is described in more detail in TS 36.300 [5]. 

In addition to the E-UTRAN functions described in TS 36.300 [5], E-UTRAN functions include: 

- Header compression and user plane ciphering; 

- MME selection when no routeing to an MME can be determined from the information provided by the UE; 

- UL bearer level rate enforcement based on UE-AMBR via means of uplink scheduling and MBR 
(e.g. by limiting the amount of UL resources granted per UE over time); 

- UL and DL bearer level admission control; 

- Transport level packet marking in the uplink, e.g. setting the DiffServ Code Point, based on the QCI of the 
associated EPS bearer. 

4.4.2 MME 

MME functions include: 
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- NAS signalling; 

- NAS signalling security; 

- Inter CN node signalling for mobility between 3GPP access networks (terminating S3); 

- UE Reachability in ECM-IDLE state (including control and execution of paging retransmission); 

- Tracking Area list management; 

- PDN GW and Serving GW selection; 

MME selection for handovers with MME change; 

- SGSN selection for handovers to 2G or 3G 3GPP access networks; 

- Roaming (S6a towards home HSS); 

- Authentication; 

- Bearer management functions including dedicated bearer establishment. 

- Lawful Interception of signalling traffic. 

NOTE: The Serving GW and the MME may be implemented in one physical node or separated physical nodes. 

4.4.3 Gateway 

4.4.3.1 General 

Two logical Gateways exist: 

- Serving GW (S-GW); 

- PDN GW (P-GW). 

NOTE: The PDN GW and the Serving GW may be implemented in one physical node or separated physical 
nodes. 

4.4.3.2 Serving GW 

The Serving GW is the gateway which terminates the interface towards E-UTRAN. 

For each UE associated with the EPS, at a given point of time, there is a single Serving GW. 

The functions of the Serving GW, for both the GTP-based and the PMIP-based S5/S8, include: 

- the local Mobility Anchor point for inter-eNodeB handover; 

- assist the eNodeB reordering function during inter-eNodeB handover by sending one or more "end marker" 
packets to the source eNodeB inmiediately after switching the path. 

- Mobility anchoring for inter-3GPP mobility (terminating S4 and relaying the traffic between 2G/3G system and 
PDN GW); 

- ECM-IDLE mode downlink packet buffering and initiation of network triggered service request procedure; 

- Lawful Interception; 

- Packet routeing and forwarding; 

- Transport level packet marking in the uplink and the downlink, e.g. setting the DiffServ Code Point, based on the 
QCI of the associated EPS bearer; 

- Accounting on user and QCI granularity for inter-operator charging; 
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- UL and DL charging per UE, PDN, and QCI 
(e.g. for roaming with home routed traffic). 

Additional Serving GW functions for the PMIP-based S5/S8 are captured in TS 23.402 [2]. 

Connectivity to a GGSN is not supported. 

4.4.3.3 PDN GW 

The PDN GW is the gateway which terminates the SGi interface towards the PDN. 

If a UE is accessing multiple PDNs, there may be more than one PDN GW for that UE, however a mix of S5/S8 
connectivity and Gn/Gp connectivity is not supported for that UE simultaneously. 

PDN GW functions include for both the GTP-based and the PMIP-based S5/S8: 

- Per-user based packet filtering (by e.g. deep packet inspection); 

- Lawful Interception; 

- UE IP address allocation; 

- Transport level packet marking in the uplink and downlink, e.g. setting the DiffServ Code Point, based on the 
QCI of the associated EPS bearer; 

- UL and DL service level charging as defined in TS 23.203 [6] 

(e.g. based on SDFs defined by the PCRF, or based on deep packet inspection defined by local policy); 

- UL and DL service level gating control as defined in TS 23.203 [6]; 

- UL and DL service level rate enforcement as defined in TS 23.203 [6] 
(e.g. by rate policing/shaping per SDF); 

- UL and DL rate enforcement based on APN-AMBR 

(e.g. by rate policing/shaping per aggregate of traffic of all SDFs of the same APN that are associated with Non- 
GBR QCIs); 

- DL rate enforcement based on the accumulated MBRs of the aggregate of SDFs with the same GBR QCI 
(e.g. by rate policing/shaping); 

DHCPv4 (server and client) and DHCPv6 (client, relay and server) functions; 

- The network does not support PPP bearer type in this version of the specification. Pre-Release 8 PPP 
functionality of a GGSN may be implemented in the PDN GW. 

Additionally the PDN GW includes the following functions for the GTP-based S5/S8: 

- UL and DL bearer binding as defined in TS 23.203 [6]; 

UL bearer binding verification; 

Editor's Note: This is to verify that the UE applies the UL packet filters correctly and does not misbehave, e.g., by 
sending packets on a "premium bearer" even though the packets do not match the UE's UL packet filters 
associated with that "premium bearer". Once the term 'UL bearer binding verification' has been defined in 
TS 23.203 this editor's note can be replaced with a corresponding reference. 

- Functionality as defined in RFC 4861 [32]. 

The P-GW provides PDN connectivity to both GERAN/UTRAN only UEs and E-UTRAN capable UEs using any of 
E-UTRAN, GERAN or UTRAN. The P-GW provides PDN connectivity to E-UTRAN capable UEs using E-UTRAN 
only over the S5/S8 interface. 

4.4.4 SGSN 

In addition to the functions described in TS 23.060 [7], SGSN functions include: 
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- Inter EPC node signalling for mobility between 2G/3G and E-UTRAN 3GPP access networks; 

- PDN and Serving GW selection: the selection of S-GW/P-GW by the SGSN is as specified for the MME; 

- MME selection for handovers to E-UTRAN 3GPP access network. 

4.4.5 GERAN 

GERAN is described in more detail in TS 43.051 [15]. 

4.4.6 UTRAN 

UTRAN is described in more detail in TS 25.401 [16]. 

4.4.7 PCRF 

4.4.7.1 General 

PCRF is the policy and charging control element. PCRF functions are described in more detail in TS 23.203 [6]. 

In non-roaming scenario, there is only a single PCRF in the HPLMN associated with one UE's IP-CAN sessionThe 
PCRF terminates the Rx interface and the Gx interface. 

In a roaming scenario with local breakout of traffic there may be two PCRFs associated with one UE's IP-CAN session: 

- H-PCRF that resides within the H-PLMN; 

- V-PCRF that resides within the V-PLMN. 

4.4.7.2 Home PCRF (H-PCRF) 

The functions of the H-PCRF include: 

terminates the Rx reference point for home network services; 

- terminates the S9 reference point for roaming with local breakout; 

- associates the sessions established over the multiple reference points (S9, Rx), for the same UE's IP-CAN 
session (PCC session binding). 

The functionality of H-PCRF is described in TS 23.203 [6]. 

4.4.7.3 Visited PCRF (V-PCRF) 

The functions of the V-PCRF include: 

- terminates the Gx and S9 reference points for roaming with local breakout; 

- terminates Rx for roaming with local breakout and visited operator's Application Function. 
The functionality of V-PCRF is described in TS 23.203 [6]. 

4.4.8 PDN GW's associated AAA Server 

The PDN Gateway may interact with a AAA server over the SGi interface. This AAA Server may maintain information 
associated with UE access to the EPC and provide authorization and other network services. This AAA Server could be 
a RADIUS or Diameter Server in an external PDN network, as defined in TS 29.061 [38]. This AAA Server is logically 
separate from the HSS and the 3GPP AAA Server. 
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4.5 Reference points 

Sl-MME:Reference point for the control plane protocol between E-UTRAN and MME. 

Sl-U: Reference point between E-UTRAN and Serving GW for the per bearer user plane tunnelling and inter 
eNodeB path switching during handover. 

S3: It enables user and bearer information exchange for inter 3GPP access network mobility in idle and/or 

active state. 

S4: It provides related control and mobility support between GPRS Core and the 3GPP Anchor function of 

Serving GW. In addition, if Direct Tunnel is not established, it provides the user plane tunnelling. 

S5: It provides user plane tunneling and tunnel management between Serving GW and PDN GW. It is used 

for Serving GW relocation due to UE mobility and if the Serving GW needs to connect to a non- 
collocated PDN GW for the required PDN connectivity. 

S6a: It enables transfer of subscription and authentication data for authenticating/authorizing user access to the 
evolved system (AAA interface) between MME and HSS. 

Gx: It provides transfer of (QoS) policy and charging rules from PCRF to Policy and Charging Enforcement 
Function (PCEF) in the PDN GW. 

S8: Inter-PLMN reference point providing user and control plane between the Serving GW in the VPLMN 

and the PDN GW in the HPLMN. S8 is the inter PLMN variant of S5. 

S9: It provides transfer of (QoS) policy and charging control information between the Home PCRF and the 

Visited PCRF in order to support local breakout function. 

SIO: Reference point between MMEs for MME relocation and MME to MME information transfer. 

Sll: Reference point between MME and Serving GW. 

S12: Reference point between UTRAN and Serving GW for user plane tunneling when Direct Tunnel is 

established. It is based on the lu-u/Gn-u reference point using the GTP-U protocol as defined between 
SGSN and UTRAN or respectively between SGSN and GGSN. Usage of S 12 is an operator configuration 
option. 

S13: It enables UE identity check procedure between MME and EIR. 

SGi: It is the reference point between the PDN GW and the packet data network. Packet data network may be 
an operator external public or private packet data network or an intra operator packet data network, e.g. 
for provision of IMS services. This reference point corresponds to Gi for 3GPP accesses. 

Rx The Rx reference point resides between the AF and the PCRF in the TS 23.203 [6]. 

When data forwarding is used as part of mobility procedures different user plane routes may be used based on the 
network configuration (e.g. direct or indirect data forwarding). These routes can be between eNodeB and RNC, eNodeB 
and SGSN, RNC and S-GW or between S-GW and SGSN. Explicit reference points are not defined for these routes. 

Protocol assumption: 

- The S 1 -U is based on GTP-U protocol; 

- The S3 is based on GTP protocol; 

- The S4 is based on GTP protocol; 

- The S5 is based on GTP protocol. PMIP variant of S5 is described in TS 23.402 [2] ; 

- The S8 is based on GTP protocol. PMIP variant of S8 is described in TS 23.402 [2]. 

- S3, S4, S5, SB, SIO and Sll interfaces are designed to manage EPS bearers as defined in clause 4.7.2. 
NOTE: Redundancy support on reference points S5 and SB should be taken into account. 
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4,6 EPS Mobility Management and Connection Management 
states 

Editor's note: The relationship and impact of the inter-system mobility to the EMM/ECM states are FES. The 

current definitions of ECM-IDLE and ECM-CONNECTED states roughly correspond to PMM-IDLE and 
PMM-CONNECTED 3G-SGSN/UTRAN states. 

4.6.1 General 

The EPS Mobility Management (EMM) states describe the Mobility Management states that result from the mobility 
management procedures e.g. Attach and Tracking Area Update procedures. 

The EPS Connection Management (ECM) states describe the signalling connectivity between the UE and the EPC. 

The ECM and EMM states are independent of each other. 

NOTE: For example, the UE has to be in the ECM-CONNECTED state in order for the network to send a 
Tracking Area Update Reject message to the UE. 

4.6.2 Definition of main EPS Mobility Management states 

4.6.2.1 EMM-DEREGISTERED 

In the EMM-DEREGISTERED state, the EMM context in MME holds no valid location or routeing information for the 
UE. The UE is not reachable by a MME, as the UE location is not known. 

In the EMM-DEREGISTERED state, some UE context can still be stored in the UE and MME, e.g. to avoid running an 
AKA procedure during every Attach procedure. 

4.6.2.2 EMM-REGISTERED 

The UE enters the EMM-REGISTERED state by a successful registration procedure which is either an Attach 
procedure or a Tracking Area Update procedure. In the EMM-REGISTERED state, the UE can receive services that 
require registration in the EPS. 

The UE location is known in the MME to at least an accuracy of the tracking area list allocated to that UE (excluding 
some abnormal cases). 

In the EMM-REGISTERED state, the UE shall: 

- always have at least one active PDN connection; 

- setup the EPS security context. 

After performing the Detach procedure, the state is changed to EMM-DEREGISTERED in the UE and in the MME. 
Upon receiving the TAU Reject and Attach Reject messages the actions of the UE and MME depend upon the 'cause 
value' in the reject message, but, in many cases the state is changed to EMM-DEREGISTERED in the UE and in the 
MME. 

If all the bearers belonging to a UE are released (e.g., after handover from EUTRAN to non-3GPP access), the MME 
shall change the MM state of the UE to EMM-DEREGISTERED. If the UE detects that all of its bearers are released, 
the UE shall change the MM state to EMM-DEREGISTERED. If the UE switches off its EUTRAN interface when 
performing handover to non-3GPP access, the UE shall automatically change its MM state to EMM-DEREGISTERED. 

The MME may perform an implicit detach any time after the UE reachable timer expires. 
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4.6.3 Definition of EPS Connection Management states 



4.6.3.1 



ECM-IDLE 



A UE is in ECM-IDLE state when no NAS signalling connection between UE and network exists. In ECM-IDLE state, 
a UE performs cell selection/reselection according to TS 36.304 [34] and PLMN selection according to TS 23.122 [10]. 

There exists no UE context in E-UTRAN for the UE in the ECM-IDLE state. There is no S1_MME and no S1_U 
connection for the UE in the ECM-IDLE state. 

In the EMM-REGISTERED and ECM-IDLE state, the UE shall: 

- perform a tracking area update if the current TA is not in the list of TAs that the UE has received from the 
network in order to maintain the registration and enable the MME to page the UE; 

- perform the periodic tracking area updating procedure to notify the EPC that the UE is available; 

- answer to paging from the MME by performing a service request procedure; 

- perform the service request procedure in order to establish the radio bearers when uplink user data is to be sent. 

The UE and the MME shall enter the ECM-CONNECTED state when the signalling connection is established between 
the UE and the MME. Initial NAS messages that initiate a transition from ECM-IDLE to ECM-CONNECTED state are 
Attach Request, Tracking Area Update Request, Service Request or Detach Request. 

The UE in the ECM-IDLE state performs the tracking area update procedure when TAI in the EMM system information 
is not in the list of TA's that the UE is registered with the network. 

When the UE is in ECM-IDLE state, the UE and the network may be unsynchronized, i.e. the UE and the network may 
have different sets of established EPS bearers. When the UE and the MME enter the ECM-CONNECTED state, the set 
of EPS Bearers is synchronized between the UE and network. 



The UE location is known in the MME with an accuracy of a serving eNodeB ID. The mobility of UE is handled by the 
handover procedure. 

The UE performs the tracking area update procedure only when explicitly triggered by the eNodeB. The eNodeB shall 
trigger the tracking area update procedure after a handover with the change of MME, which may happen due to UE 
mobility or due to load rebalancing. It is up to RAN configuration whether the eNodeB triggers the tracldng area update 
procedure after handover without MME change on condition that the current TAI is not in the list of TA's that the UE 
has registered with the network. 

For a UE in the ECM-CONNECTED state, there exists a signalling connection between the UE and the MME. The 
signalling connection is made up of two parts: an RRC connection and an S1_MME connection. 

The SI release procedure changes the state at both UE and MME from ECM-CONNECTED to ECM-IDLE. 

NOTE: The UE may not receive the indication for the SI release, e.g. due to radio link error or out of coverage. 

In this case, there can be temporal mismatch between the ECM-state in the UE and the ECM-state in the 
MME. 

After a signalling procedure, the MME may decide to release the signalling connection to the UE, after which the state 
at both the UE and the MME is changed to ECM-IDLE. 

Editor's note: There are some error cases where the UE also changes to EMM-IDLE. The details are FES. 

When a UE changes to ECM-CONNECTED state and if a radio bearer cannot be established, the corresponding EPS 
bearer is deactivated. 



4.6.3.2 



ECM-CONNECTED 
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4.6.4 State transition and functions 




EMM-DEREGISTERED 




Detach, 
Attach Reject, 
TAD reject, 

EUTRAN interface switched off due to Non-3GPP handover. 
All bearers deactivated. 



Attach accept, 
TAU accept 




EMM-REGISTERED 




Figure 4.6.4-1 : EMM state model in UE 
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Figure 4.6.4-2: EMM state model in MME 
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Figure 4.6.4-3: ECM state model in UE 
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Figure 4.6.4-4: ECM state model in MME 
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4.7 Overall QoS concept 

4.7.1 PDN connectivity service 

The Evolved Packet System provides IP connectivity between a UE and a PLMN external packet data network. This is 
referred to as PDN Connectivity Service. 

The PDN Connectivity Service supports the transport of one or more Service Data Flows (SDFs) defined in 
TS 23.203 [6]. 

4.7.2 The EPS bearer 

4.7.2.1 The EPS bearer in general 

For E-UTRAN access to the EPC the PDN connectivity service is provided by an EPS bearer in case of GTP-based 
S5/S8, and by an EPS bearer concatenated with IP connectivity between Serving GW and PDN GW in case of PMIP- 
based S5/S8. 

An EPS bearer uniquely identifies an SDF aggregate between a UE and a PDN GW in case of GTP-based S5/S8, and 
between UE and Serving GW in case of PMIP-based S5/S8. 

The term 'SDF aggregate' is defined in TS 23.203 [6]. 

An EPS bearer is the level of granularity for bearer level QoS control in the EPC/E-UTRAN. That is, SDFs mapped to 
the same EPS bearer receive the same bearer level packet forwarding treatment (e.g. scheduling policy, queue 
management policy, rate shaping policy, RLC configuration, etc.). Providing different bearer level QoS to two SDFs 
thus requires that a separate EPS bearer is established for each SDF. 

NOTE 1: In addition but independent to bearer level QoS control, the PCC framework allows an optional 

enforcement of service level QoS control on the granularity of SDFs independent of the mapping of SDFs 
to EPS bearers. 

One EPS bearer is established when the UE connects to a PDN, and that remains established throughout the lifetime of 
the PDN connection to provide the UE with always-on IP connectivity to that PDN. That bearer is referred to as the 
default bearer. Any additional EPS bearer that is established to the same PDN is referred to as a dedicated bearer. The 
distinction between default and dedicated bearers should be transparent to the access network (e.g. E-UTRAN). 

An UpLink Traffic Flow Template (UL TFT) is a set of uplink packet filters. A DownLink Traffic Flow Template (DL 
TFT) is a set of downlink packet filters. Every EPS bearer is associated with an UL TFT in the UE and a DL TFT in the 
PCEF. 

NOTE 2: The evaluation precedence order of the filters associated with the default bearer, in relation to those 
associated with the dedicated bearers, is up to operator configuration. It is possible to "force" certain 
SDFs onto the default bearer by setting the evaluation precedence order of the corresponding filters to a 
value that is lower than the values used for filters associated with the dedicated bearers. It is also possible 
use the default bearer for traffic that does not match any of the filters associated with the dedicated 
bearers. In this case, the evaluation precedence order of the corresponding filter(s) (e.g., a "match all 
filter") need to be set to a value that is higher than the values used for filters associated with dedicated 
bearers. 

The initial bearer level QoS parameter values of the default bearer are assigned by the network, based on subscription 
data (in case of E-UTRAN the MME sets those initial values based on subscription data retrieved from HSS). The 
PCEF may change those values based in interaction with the PCRF or based on local configuration. 

The decision to establish or modify a dedicated bearer can only be taken by the EPC, and the bearer level QoS 
parameter values are always assigned by the EPC. Therefore, the MME shall not modify the bearer level QoS parameter 
values received on the S 11 reference point during establishment or modification of a dedicated bearer. Instead, the 
MME shall only transparently forwards those values to the E-UTRAN. Consequently, "QoS negotiation" between the 
E-UTRAN and the EPC during dedicated bearer establishment / modification is not supported. The MME may, 
however, reject the establishment or modification of a dedicated bearer (e.g. in case the bearer level QoS parameter 
values sent by the PCEF over a GTP based S8 roaming interface do not comply with a roaming agreement). 
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Editor's Note: It is FFS in case of GTP based roaming how an MME in the VPLMN can enforce roaming restrictions 
on an 'EPS subscribed QoS profile' received from the HSS in the HPLMN during the Attach procedure. 

The distinction between default and dedicated bearers should be transparent to the access network (e.g. E-UTRAN). 

An EPS bearer is referred to as a GBR bearer if dedicated network resources related to a Guaranteed Bit Rate (GBR) 
value that is associated with the EPS bearer are permanently allocated (e.g. by an admission control function in the 
eNodeB) at bearer establishment/modification. Otherwise, an EPS bearer is referred to as a Non-GBR bearer. 

NOTE 3: Admission control can be performed at establishment / modification of a Non-GBR bearer even though a 
Non-GBR bearer is not associated with a GBR value. 

A dedicated bearer can either be a GBR or a Non-GBR bearer. A default bearer shall be a Non-GBR bearer. 

NOTE 4: A default bearer remains permanently established to provide the UE with always-on IP connectivity to a 
certain PDN. That motivates the restriction of a default bearer to bearer type Non-GBR. 



4.7.2.2 The EPS bearer with GTP-based S5/S8 
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Figure 4.7.2.2-1 : Two unicast EPS bearers (GTP-u based S5/S8) 

An EPS bearer is realized by the following elements: 

An UL TFT in the UE maps an SDF to an EPS bearer in the uplink direction. Multiple SDFs can be multiplexed 
onto the same EPS bearer by including multiple uplink packet filters in the UL TFT; 

- A DL TFT in the PDN GW maps an SDF to an EPS bearer in the downlink direction. Multiple SDFs can be 
multiplexed onto the same EPS bearer by including multiple downlink packet filters in the DL TFT; 

- A radio bearer (defined in TS 36.300 [5]) transports the packets of an EPS bearer between a UE and an eNodeB. 
There is a one-to-one mapping between an EPS bearer and a radio bearer; 

- An SI bearer transports the packets of an EPS bearer between an eNodeB and a Serving GW; 

- An S5/S8 bearer transports the packets of an EPS bearer between a Serving GW and a PDN GW; 

- A UE stores a mapping between an uplink packet filter and a radio to create the mapping between an SDF and a 
radio bearer in the uplink; 

- A PDN GW stores a mapping between a downlink packet filter and an S5/S8 bearer to create the mapping 
between an SDF and an S5/S8 bearer in the downlink; 

- An eNodeB stores a one-to-one mapping between a radio bearer and an S 1 to create the mapping between a radio 
bearer and an S 1 bearer in both the uplink and downlink; 
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- A Serving GW stores a one-to-one mapping between an SI bearer and an S5/S8 bearer to create the mapping 
between an SI bearer and an S5/S8 bearer in both the uphnk and downhnk. 

4.7.2.3 The EPS bearer with PM IP-based S5/S8 

See clause 4.6 in TS 23.402 [2]. 

4.7.3 Bearer level QoS parameters 

The bearer level (i.e. per bearer or per bearer aggregate) QoS parameters are QCI, ARP, GBR, MBR, and AMBR 
described in this section. 

Each EPS bearer (GBR and Non-GBR) is associated with the following bearer level QoS parameters: 

- QoS Class Identifier (QCI); 

- Allocation and Retention Priority (ARP). 

A QCI is a scalar that is used as a reference to access node-specific parameters that control bearer level packet 
forwarding treatment (e.g. scheduling weights, admission thresholds, queue management thresholds, link layer protocol 
configuration, etc.), and that have been pre-configured by the operator owning the access node (e.g. eNodeB). A one-to- 
one mapping of standardized QCI values to standardized characteristics is captured TS 23.203 [6]. 

NOTE 1: On the radio interface and on SI, each PDU (e.g. RLC PDU or GTP-u PDU) is indirectly associated with 
one QCI via the bearer identifier carried in the PDU header. The same applies to the S5 and S8 interfaces 
if they are based on GTP-u. 

The primary purpose of ARP is to decide whether a bearer establishment / modification request can be accepted or 
needs to be rejected in case of resource limitations (typically available radio capacity in case of GBR bearers). In 
addition, the ARP can be used (e.g. by the eNodeB) to decide which bearer(s) to drop during exceptional resource 
limitations (e.g. at handover). Once successfully established, a bearer's ARP shall not have any impact on the bearer 
level packet forwarding treatment (e.g. scheduling and rate control). Such packet forwarding treatment should be solely 
determined by the other bearer level QoS parameters: QCI, GBR, MBR, and AMBR. 

NOTE 2: The ARP should be understood as "Priority of Allocation and Retention"; not as "Allocation, Retention, 
and Priority". 

NOTE 3: Video telephony is one use case where it may be beneficial to use EPS bearers with different ARP values 
for the same UE. In this use case an operator could map voice to one bearer with a higher ARP, and video 
to another bearer with a lower ARP. In a congestion situation (e.g. cell edge) the eNB can then drop the 
"video bearer" without affecting the "voice bearer". This would improve service continuity. 

NOTE 4: The ARP may also be used to free up capacity in exceptional situations, e.g. a disaster situation. In such a 
case the eNB may drop "low ARP bearers" to free up capacity. 

Each GBR bearer is additionally associated with the following bearer level QoS parameters: 

- Guaranteed Bit Rate (GBR); 

- Maximum Bit Rate (MBR). 

The GBR denotes the bit rate that can be expected to be provided by a GBR bearer. The MBR limits the bit rate that can 
be expected to be provided by a GBR bearer (e.g. excess traffic may get discarded by a rate shaping function). See 
clause 4.7.4 for further details on GBR and MBR. 

Each APN is associated with the following IP-CAN session level QoS parameter: 

- per APN Aggregate Maximum Bit Rate (APN- AMBR). 

The APN- AMBR is a subscription parameter stored per APN in the HSS. It limits the aggregate bit rate that can be 
expected to be provided across all Non-GBR bearers and across all PDN connections of the same APN (e.g. excess 
traffic may get discarded by a rate shaping function). Each of those Non-GBR bearers could potentially utilize the entire 
APN- AMBR, e.g. when the other Non-GBR bearers do not carry any traffic. GBR bearers are outside the scope of 
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APN-AMBR. The P-GW enforces the APN-AMBR in downlink. Enforcement of APN-AMBR in uplink is done in the 
UE and additionally in the P-GW. 

NOTE 5: All simultaneous active PDN connections of a UE that are associated with the same APN shall be 
provided by the same PGW (see clause 5.10.1). 

Each UE is associated with the following bearer level QoS parameter: 

- per UE Aggregate Maximum Bit Rate (UE-AMBR). 

The UE-AMBR is Hmited by a subscription parameter stored in the HSS. The MME shall set the used UE-AMBR to the 
sum of the APN-AMBR of all active APNs up to the value of the subscribed UE-AMBR. The UE-AMBR limits the 
aggregate bit rate that can be expected to be provided across all Non-GBR bearers of a UE (e.g. excess traffic may get 
discarded by a rate shaping function). Each of those Non-GBR bearers could potentially utilize the entire UE-AMBR, 
e.g. when the other Non-GBR bearers do not carry any traffic. GBR bearers are outside the scope of UE AMBR. The 
E-UTRAN enforces the UE-AMBR in uplink and downlink. 

The GBR and MBR denote bit rates of traffic per bearer while UE-AMBR/ APN- AMBR denote bit rates of traffic per 
group of bearers. Each of those QoS parameters has an uplink and a downlink component. On S1_MME the values of 
the GBR, MBR, and AMBR refer to the bit stream excluding the GTP-u/IP header overhead of the tunnel on S1_U. 

One 'EPS subscribed QoS profile' is defined for each APN permitted for the subscriber. It contains the bearer level QoS 
parameter values for that APN's default bearer (QCI and ARP) and the APN-AMBR. 

NOTE: Subscription data related to bearer level QoS parameter values for dedicated bearers is specified in 
TS 23.203 [6]. 

4.7.4 Support for Application / Service Layer Rate Adaptation 

Neither the EPC nor the E-UTRAN supports any explicit feedback to trigger a rate adaptation scheme at the application 
/ service / transport layer. 

The MBR of a particular GBR bearer shall be set equal to the GBR. 

NOTE: Support for "MBR > GBR" bearers may be introduced in a future release. 

The EPC does not support E-UTRAN-initiated "QoS re-negotiation". That is, the EPC does not support an eNodeB 
initiated bearer modification procedure. If an eNodeB can no longer sustain the GBR of an active GBR bearer then the 
eNodeB should simply trigger a deactivation of that bearer. 

4.7.5 Application of PCC in the Evolved Packet System 

The Evolved Packet System applies the PCC framework as defined in TS 23.203 [6] for QoS policy and charging 
control. PCC functionality is present in the AF, PCEF and PCRF. 

An EPS needs to support both PCEF and PCRF functionality to enable dynamic policy and charging control by means 
of installation of PCC rules based on user and service dimensions. However, an EPS may only support PCEF 
functionality in which case it shall support static policy and charging control. 

NOTE: The local configuration of PCEF static policy and charging control functionality is not subject to 
standardization. The PCEF static policy and control functionality is not based on subscription 
information. 

The following applies to the use of dynamic policy and charging control in EPS: 

- The service level (per SDF) QoS parameters are conveyed in PCC rules (one PCC rule per SDF) over the S7 
reference point. The service level QoS parameters consist of a QoS Class Identifier (QCI) Allocation and 
Retention Priority (ARP) and authorised Guaranteed and Maximum Bit Rate values for uplink and downlink. 
The QCI is a scalar that represents the QoS characteristics that the EPS is expected to provide for the SDF. ARP 
is an indicator of the priority of allocation and retention for the SDF. The service level ARP assigned by PCRF 
in a PCC rule may be different from the bearer level ARP stored in subscription data; 
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- The set of standardized QCIs and their characteristics that the PCRF in an EPS can select from is provided in 
TS 23.203 [6]. It is expected that the PCRF selects a QCI in such a way that the IP-CAN receiving it can support 
it; 

- It is not required that an IP-CAN supports all standardized QCIs; 

- In the case of IP address configuration subsequent to initial attachment, the PDN GW/PCEF shall notify the 
PCRF of the UE's IP address when it is assigned. If the PCRF response leads to an EPS bearer modification the 
PDN GW should initiate a bearer update procedure; 

- For local breakout, the visited network has the capability to reject the QoS authorized by the home network 
based on operator policies. 

The following applies regardless of whether dynamic or static policy and charging control is used in EPS: 

- For E-UTRAN the value of the ARP of an EPS bearer is identical to the value of the ARP of the SDF(s) mapped 
to that EPS bearer; 

- For the same UE/PDN connection: SDFs associated with different QCIs or with the same service-level QCI but 
different ARP shall not be mapped to the same EPS bearer; 

- The bearer level QCI of an EPS bearer is identical to the value of the QCI of the SDF(s) mapped to that EPS 
bearer. 

Editor's note: It is FES whether the PCRF may select a different QCI due to a handover to a different RAT type. 

Editor's note: The inclusion in TS 23.203 of ARP and the associated description of the information that the PCRF 
takes into account to take a policy decision on ARP is FFS. 

5 Functional description and information flows 
5.1 Control and user planes 

NOTE: 

- Refer to TS 23.402 [2] for the corresponding protocol stack for PMIP based S5/S8. 

- Refer to TS 23.203 [6] for the corresponding protocol stack for Policy Control and Charging (PCC) 
function related reference points. 

5.1.1 Control Plane 
5.1.1.1 General 

The control plane consists of protocols for control and support of the user plane functions: 

- controlling the E-UTRA network access connections, such as attaching to and detaching from E-UTRAN; 

- controlling the attributes of an established network access connection, such as activation of an IP address; 

- controlling the routeing path of an established network connection in order to support user mobility; and 

- controlling the assignment of network resources to meet changing user demands. 
The following control planes are used in E-UTRAN mode. 
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Legend: 

SI Application Protocol (S1-AP): Application Layer Protocol between the eNodeB and the MME. 
SCTP for the control plane (SCTP): This protocol guarantees delivery of signalling messages between 
MME and eNodeB (S1). SCTP is defined in RFC 2960 [35]. 

Figure 5.1.1.2-1: Control Plane for 81 -MME Interface 
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UE-MME 



NAS 



RRC 



PDCP 



RLC 

mac' 



L1 



UE 



Relay 




RRC 




S1-AP 


PDCP 


SCTP . 


RLC 


IP 


MAC 


L2 


L1 


L1 



LTE-Uu 



eNodeB 



S1-MME 



NAS 



S1-AP 
SCTP 

~1p 



MME 



Legend: 

NAS: The NAS protocol supports mobility management functionality and user plane bearer activation, 
modification and deactivation. It is also responsible of ciphering and integrity protection of NAS signalling. 
LTE-Uu: The radio protocol of E-UTRAN between the UE and the eNodeB is specified in TS 36.300 [5]. 

Figure 5.1 .1 .3-1 : Control Plane UE - MME 
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Legend: 

GPRS Tunnelling Protocol for the control plane (GTP-C): This protocol tunnels signalling messages 
between SGSN and MME (S3). 

User Datagram Protocol (UDP): This protocol transfers signalling messages. UDP is defined in 
RFC 768 [26]. 

Figure 5.1.1.4-1 : Control Plane for S3 Interface 



5.1.1.5 SGSN-S-GW 
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Legend: 

GPRS Tunnelling Protocol for the control plane (GTP-C): This protocol tunnels signalling messages 
between SGSN and S-GW (S4). 

User Datagram Protocol (UDP): This protocol transfers signalling messages. UDP is defined in 
RFC 768 [26]. 

Figure 5.1.1.5-1 : Control Plane for S4 interface 
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Legend: 

GPRS Tunnelling Protocol for the control plane (GTP-C): This protocol tunnels signalling messages 
between S-GW and P-GW (S5 or S8). 

User Datagram Protocol (UDP): This protocol transfers signalling messages between S-GW and P-GW. 
UDP is defined in RFC 768 [26]. 

Figure 5.1.1.6-1 : Control Plane for 85 and 88 interfaces 



5.1.1.7 MME-MME 
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Legend: 

GPRS Tunnelling Protocol for the control plane (GTP-C): This protocol tunnels signalling messages 
between MMEs (S10). 

User Datagram Protocol (UDP): This protocol transfers signalling messages between MMEs. UDP is 
defined in RFC 768 [26]. 

Figure 5.1.1.7-1 : Control Plane for 810 interface 
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Legend: 



GPRS Tunnelling Protocol for the control plane (GTP-C): This protocol tunnels signalling messages 
between MME and S-GW (S11). 

User Datagram Protocol (UDP): This protocol transfers signalling messages. UDP is defined in 
RFC 768 [26]. 

Figure 5.1.1.8-1: Control Plane for 811 interface 



5.1.1.9 MME-HSS 

Editor's note: This section shall specify the protocol stack on the control plane of the S6a interface. 

5.1.1.10 MME - EIR 

Editor's note: This section shall specify the protocol stack on the control plane of the S 13 reference point. 
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5.1.2.1 
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UE - P-GW user plane with E-UTRAN 
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GPRS Tunnelling Protocol for the user plane (GTP-U): This protocol tunnels user data between 
eNodeB and the S-GW as well as between the S-GW and the P-GW in the backbone network. GTP shall 
encapsulate all end user IP packets. 

MME controls the user plane tunnel establishment and establishes User Plane Bearers between eNodeB 
and S-GW. 

UDP/IP: These are the backbone network protocols used for routeing user data and control signalling. 
LTE-Uu:The radio protocols of E-UTRAN between the UE and the eNodeB are specified in TS 36.300 [5]. 



Figure 5.1.2.1-1: User Plane 



5.1.2.2 eNodeB -S-GW 



GTP 






GTP-U 






UDP 


UDP 






IP 


IP 






L2 


L2 






L1 


L1 







eNodeB S-GW 



Legend: 

GPRS Tunnelling Protocol for the user plane (GTP-U): This protocol tunnels user data between 
eNodeB and S-GW. 

User Datagram Protocol (UDP): This protocol transfers user data. UDP is defined in RFC 768 [26]. 
Figure 5.1.2.2-1 : User Plane for eNodeB - S-GW 
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5.1 .2.3 UE - PDN GW user plane with 2G access via the S4 interface 
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Legend: 



GPRS Tunnelling Protocol for the user plane (GTP-U): This protocol tunnels user data between SGSN 
and the S-GW as well as between the S-GW and the P-GW in the backbone network. GTP shall 
encapsulate all end user IP packets. 

UDP/IP: These are the backbone network protocols used for routeing user data and control signalling. 
Protocols on the Urn and the Gb interfaces are described in TS 23.060 [7]. 



Figure 5.1.2.3-1 : User Plane for A/Gb mode 
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5.1 .2.4 UE - PDN GW user plane with 3G access via the S12 interface 
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Legend: 



GPRS Tunnelling Protocol for the user plane (GTP-U): This protocol tunnels user data between 
UTRAN and the S-GW as well as between the S-GW and the P-GW in the backbone network. GTP shall 
encapsulate all end user IP packets. 

UDP/IP: These are the backbone network protocols used for routeing user data and control signalling. 
Protocols on the Uu interface are described in TS 23.060 [7]. 

SGSN controls the user plane tunnel establishment and establish a Direct Tunnel between UTRAN and 
S-GW as shown in Figure 5.1 .2.4-1 . 



Figure 5.1.2.4-1: User Plane for UTRAN mode and Direct Tunnel on SI 2 
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5.1 .2.5 UE - PDN GW user plane with 3G access via the S4 interface 
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NOTE: Please refer to TS 23.402 [2] for the corresponding stack for PMIP based S5/S8. 
Legend: 

GPRS Tunnelling Protocol for the user plane (GTP-U): This protocol tunnels user data between 
UTRAN and the SGSN, between SGSN and S-GW as well as between the S-GW and the P-GW in the 
backbone network. GTP shall encapsulate all end user IP packets. 

UDP/IP: These are the backbone network protocols used for routeing user data and control signalling. 
Protocols on the Uu and the lu interfaces are described in TS 23.060 [7]. 

SGSN controls the user plane tunnel establishment and establishes a tunnel between SGSN and S-GW. If 
Direct Tunnel is established between UTRAN and S-GW, see Figure 5.1 .2.4-1 . 

Figure 5.1.2.5-1 : User Plane for lu mode 

5.2 Identities 

5.2.1 EPS bearer identity 

An EPS bearer identity uniquely identifies an EPS bearer for one UE accessing via E-UTRAN. The EPS Bearer Identity 
is allocated by the MME. There is one to one mapping between EPS RB and EPS Bearer, and the mapping between 
EPS RB Identity and EPS Bearer Identity is made by E-UTRAN. 

When there is a mapping between an EPS bearer and a PDP context, the same identity value is used for the EPS bearer 
ID and the NSAPI/RAB ID. 

5.2.2 Globally Unique Temporary UE Identity 

The MME shall allocate a Globally Unique Temporary Identity (GUTI) to the UE. 
The GUTI has two main components: 

one that uniquely identifies the MME which allocated the GUTI; and 
- one that uniquely identifies the UE within the MME that allocated the GUTI. 
Within the MME, the mobile is identified by the M-TMSI. 

The Globally Unique MME Identifier (GUMMEI) is constructed from MCC, MNC and MME Identifier (MMEI). 
In turn the MMEI is constructed from an MME Group ID (MMEGI) and an MME Code (MMEC). 
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The GUTI is constructed from the GUMMEI and the M-TMSI. 

For paging, the mobile is paged with the S-TMSI. The S-TMSI is constructed from the MMEC and the M-TMSI. 

The operator needs to ensure that the MMEC is unique within the MME pool area and, if overlapping pool areas are in 
use, unique within the area of overlapping MME pools. 

The GUTI is used to support subscriber identity confidentiality, and, in the shortened S-TMSI form, to enable more 
efficient radio signalling procedures (e.g. paging and Service Request). 

5.2.3 Tracking Area Identity (TAI) 

This is the identity used to identify tracking areas. The Tracking Area Identity is constructed from the MCC (Mobile 
Country Code), MNC (Mobile Network Code) and TAC (Tracking Area Code). 

NOTE: Changes in the TAI of a cell can occur but are normally infrequent and linked with 0+M activity. 

5.2.4 eNodeB S1 -AP UE Identity (eNB S1 -AP UE ID) 

This is the temporary identity used to identify a UE on the SI -MME reference point within the eNodeB. It is unique 
within the eNodeB per SI -MME reference point instance. 

5.2.5 MME S1 -AP UE Identity (MME S1 -AP UE ID) 

This is the temporary identity used to identify a UE on the SI -MME reference point within the MME. It is unique 
within the MME per SI -MME reference point instance. 

5.3 Authentication, security and location management 
5.3.1 IP address allocation 
5.3.1.1 General 

A UE shall perform the address allocation procedures for at least one IP address (either IPv4 or IPv6) after the default 
bearer activation if no IPv4 address is allocated during the default bearer activation. 

One of the following ways shall be used to allocate IP addresses for the UE: 

a) The HPLMN allocates the IP address to the UE when the default bearer is activated (dynamic or static HPLMN 
address); 

b) The VPLMN allocates the IP address to the UE when the default bearer is activated (dynamic VPLMN address); 
or 

c) The PDN operator or administrator allocates an (dynamic or static) IP address to the UE when the default bearer 
is activated (External PDN Address Allocation). 

The IP address allocated for the UE's default bearer shall also be used for the UE's dedicated bearers towards the same 
PDN. The IP address allocation for the multiple PDN GW case is handled with the same set of mechanisms as Attach. 

PDN types IPv4, IPv6 and IPv4v6 are supported. An EPS Bearer of PDN type IPv4v6 may be associated with one IPv4 
address only, with one IPv6 address/prefix only or with both one IPv4 and one IPv6 address/prefix. PDN type IPv4 is 
associated with an IPv4 address. PDN type IPv6 is associated with an IPv6 address/prefix. PDN types IPv4 and IPv6 are 
utilised in case the UE and/or the PDN GW support IPv4 addressing only or IPv6 addressing/prefix only; or operator 
preferences dictate the use of a single IP version only, or the subscription is limited to IPv4 only or IPv6 only. In 
addition, PDN type IPv4 and IPv6 are utilised for interworking with nodes of earlier releases. 

The UE sets the PDN type during the Attach procedure based on its IP stack configuration as follows: 

- A UE, which is IPv6 and IPv4 capable, shall request for PDN type IPv4v6. 
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- A UE, which is only IPv4 capable, shall always request for PDN type IPv4. 

- A UE, which is only IPv6 capable, shall always request for PDN type IPv6. 

- When the IP version capability of the UE is unknown in the UE (as in the case when the MT and TE are 
separated and the capability of the TE is not known in the MT), the UE shall request for PDN type IPv4v6. 

In case the UE requests PDN type IPv4v6, but the operator preferences dictate the use of a single IP version only, the 
PDN type may be changed to a single address PDP type (IPv4 or IPv6) and a reason cause of "network preference" 
returned to the UE. In this case the UE should not request another PDN connection for the other IP version. In case the 
UE requests PDN type IPv4v6, but the operator uses single addressing per bearer due to interworking with nodes of 
earlier releases, the PDN type may be changed to a single IP version only and a reason cause of "single address bearers 
only" returned to the UE. In this case the UE can request another PDN connection for the other IP version using the UE 
requested PDN connectivity procedure to the same APN with a single address PDN type (IPv4 or IPv6) other than the 
one already activated. 

During inter-RAT mobility between EUTRAN and UTRAN/GERAN, an EPS bearer with PDN type IPv4v6 shall be 
mapped one-to-one to PDP type IPv4v6. 

During inter-RAT mobility between E-UTRAN and UTRAN/GERAN, an EPS bearer with PDN type IPv4 shall be 
mapped one-to-one to a PDP context of PDP type IPv4. An EPS bearer with PDN type IPv6 shall be mapped one-to-one 
to a PDP context of PDP type IPv6. 

It is the HPLMN operator that shall define in the subscription whether a dynamic HPLMN or VPLMN address may be 
used. 

The EPS UE may indicate to the network within the Protocol Configuration Options element that the UE wants to 
obtain the IPv4 address with DHCPv4: 

- the UE may indicate that it prefers to obtain an IPv4 address as part of the default bearer activation procedure. In 
such a case, the UE relies on the EPS network to provide IPv4 address to the UE as part of the default bearer 
activation procedure. 

- the UE may indicate that it prefers to obtain the IPv4 address after the default bearer setup by DHCPv4. That is, 
when the EPS network supports DHCPv4 and allows that, it does not provide the IPv4 address for the UE as part 
of the default bearer activation procedures. The network may respond to the UE by setting the relevant field to 
0.0.0.0. After the default bearer establishment procedure is completed, the UE uses the connectivity with the EPS 
and initiates the IPv4 address allocation on its own using DHCPv4. The UE sends DHCPv4 Discover message 
(see details in sub-clause 5.3.1.2.4). However, if the EPS network provides IPv4 address to the UE as part of the 
default bearer activation procedure, the UE should accept the IPv4 address indicated in the default bearer 
activation procedure. 

- if the UE sends no Address Allocation Preference, the PDN GW determines whether to use DHCPv4 or not 
based on per APN configuration 

Both EPS network elements and UE shall support the following mechanisms: 

a. IPv4 address allocation via default bearer activation, if IPv4 is supported. 

b. /64 IPv6 prefix allocation via IPv6 Stateless Address autoconfiguration according to RFC 4862 [18], if IPv6 is 
supported; 

Furthermore, the Protocol Configuration Options may be used during bearer activation to configure parameters which 
are needed for IP address allocation. 

Both EPS network elements and UE may optionally support the following mechanisms: 

a. IPv4 address allocation and IPv4 parameter configuration after the attach procedure via DHCPv4 according to 
RFC 2131 [19] and RFC 4039 [25]; 

b. IPv6 parameter configuration via Stateless DHCPv6 according to RFC 3736 [20]; 

c. Allocation of a static Ipv4 address and/or a static IPv6 prefix based on subscription data in the HSS. 

If the static IP address/prefix is not stored in the HSS subscription record, it may be configured on a per-user per- APN 
basis in the DHCP/Radius/Diameter server and the PDN GW retrieves the IP address/prefix for the UE from the 
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DHCP/Radius/Diameter server. In this case, static IP address/prefix is allocated by the same procedures as the dynamic 
IP address/prefix allocation. 

The following clauses describe how the above listed IP address allocation mechanisms work when GTP based S5/S8 is 
used. The way of working of the IP address allocation mechanisms for PMIP based S5/S8 can be found in 
TS 23.402 [2] .The procedures can be used both for PLMN (VPLMN/HPLMN) or external PDN based IP address 
allocation. Note it is transparent to the UE whether the PLMN or the external PDN allocates the IP address. 

In order to support DHCP based IP address configuration, the PDN GW shall act as the the DHCP server for HPLMN 
assigned dynamic and static and VPLMN assigned dynamic IP addressing. When DHCP is used for external PDN 
assigned addressing and parameter configuration, the PDN GW shall act as the DHCP server towards the UE and it 
shall act as the DHCP client towards the external DHCP server. The Serving GW does not have any DHCP 
functionality. It forwards all packets to and from the UE including DHCP packets as normal. 

Editor's note: It is FES if additional security measures need to be taken in the case of DHCPv4 and DHCPv6. 

IPv6 Stateless Address autoconfiguration [18] is the basic mechanism to allocate /64 IPv6 prefix to the UE. 
Additionally, shorter than /64 IPv6 prefix delegation via DHCPv6, REC 3633 [21] may be provided, if it is supported 
by the PDN-GW. 

During the attach procedure and default bearer establishment, the PDN GW sends the IPv6 prefix and Interface 
Identifier to the SGW, and then the S-GW forwards the IPv6 prefix and Interface Identifier to the MME or to the SGSN. 
The MME or the SGSN forwards the IPv6 Interface Identifier to the UE. Even if the UE receives the IPv6 prefix in the 
Attach Accept message, it shall ignore it. 

Editor's note: It is a stage 3 matter if the MME or the Rel-8 SGSN forwards the whole IPv6 address or only the 
Interface Identifier to the UE. 

5.3.1 .2 IP address allocation nnechanisnns for GTP based S5/S8 

5.3.1 .2.1 IPv4 address allocation via default bearer activation 

In this case the IP address is provided to the UE as part of the default bearer activation. 

When the PLMN allocates the IP address, it is the PDN-GW's responsibility to allocate and release the IP address. The 
PDN GW may use an internal address pool in this case. The PDN GW allocates an IPv4 address upon default bearer 
activation and it releases the IPv4 address upon default bearer de-activation for a given UE. 

When the IP address is allocated from the external PDN, it is the PDN GW's responsibility to obtain the IP address from 
the external PDN, allocate and release the IP address. The PDN GW may use DHCPv4 to obtain the IP address from the 
external PDN. If RADIUS or Diameter is used towards the external PDN as described in TS 29.061 [38], the IP address 
can be fetched as part of these procedures. If DHCPv4 is used, the PDN GW functions as the DHCPv4 Client. If 
RADIUS is used, the PDN GW functions as the RADIUS CHent. If Diameter is used, the PDN GW functions as the 
Diameter Client. 

5.3.1 .2.2 IPv6 prefix allocation via IPv6 stateless address autoconfiguration 

When the PLMN allocates the IPv6 prefix then it is the PDN GW responsibility to allocate and release the IPv6 prefix. 
The PDN GW may use an internal prefix pool in this case. The PDN GW allocates a globally unique /64 IPv6 prefix via 
Router Advertisement to a given UE. 

When the IPv6 prefix is allocated from the external PDN, it is the PDN GW's responsibility to obtain the IPv6 prefix for 
external PDN, allocate and release the IPv6 prefix. The PDN GW may use DHCPv6 to obtain the IPv6 prefix from the 
external PDN. In this context, the PDN GW shall act as a DHCP client rather than a requesting router as defined in 
prefix delegation. If RADIUS or Diameter is used towards the external PDN as described in TS 29.061 [38], the IPv6 
prefix can be fetched as part of these procedures. If DHCPv6 is used, the PDN-GW functions as the DHCPv6 Client. If 
RADIUS is used, the PDN GW functions as the RADIUS CHent. If Diameter is used, the PDN GW functions as the 
Diameter Client. 

The procedure of the stateless IPv6 address autoconfiguration is the following: After the attach procedure and default 
bearer establishment, the UE may send a Router Solicitation message to the PDN GW to solicit a Router Advertisement 
message. The PDN-GW sends a Router Advertisement message (solicited or unsolicited) to the UE. The Router 
Advertisement messages shall contain the same prefix as the one provided during the attach procedure (if it was 
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provided). During the attach procedure if the UE receives the IPv6 prefix it shall ignore the prefix included in the 
Attach Accept message. 

Editor's note: It is FES if the PDN GW needs to send the IPv6 prefix to the MME/SGSN via S-GWin the Create 
Default Bearer Response and to the UE in the Attach Accept message. This is used to inform the 
MME/SGSN of the IPv6 prefix allocated to the UE. 

After the UE has received the Router Advertisement message, it constructs its full IPv6 address via IPv6 Stateless 
Address autoconfiguration in accordance with REG 4862 [18]. Eor privacy, REG 3041 [39], the UE may change the 
interface identifier used to generate full IPv6 addresses, without involving the network. 

Any prefix that the PDN GW advertises to the UE is globally unique. The PDN GW shall also record the relationship 
between the UE identities and the allocated IPv6 prefix. Because any prefix that the PDN GW advertises to the UE is 
globally unique, there is no need for the UE to perform Duplicate Address Detection for any IPv6 address configured 
from the allocated IPv6 prefix. The PDN GW shall respond back with a Neighbor Advertisement upon receiving a 
Neighbor Solicitation message from the UE. Eor example, it is possible for the UE to perform Neighbor Unreachability 
Detection towards the PDN GW, as defined in REG 4861 [32]. 

5.3.1 .2.3 IPv6 parameter configuration via stateless DHCPv6 

The UE may use stateless DHCPv6 for additional parameter configuration. The PDN GW acts as the DHCP server. 
When PLMN based parameter configuration is used, the PDN GW provides the requested parameters from locally 
provisioned database. When external PDN based parameter configuration is used, the PDN GW obtains the requested 
configuration parameters from the external PDN as described in the previous sections. When the PDN GW acts as a 
DHCPv6 server towards the UE, the PDN GW may act as DHCPv6 client towards the external PDN to request the 
configuration parameters for the UE. If RADIUS or Diameter is used towards the external PDN as described in 
TS 29.061 [38], the the requested configurataion paramters can be fetched as part of these procedures. 

5.3.1 .2.4 IPv4 address allocation and IPv4 parameter configuration via DHCPv4 

When the PLMN allocates the IPv4 address then the PDN GW responsibility is to allocate and release the IPv4 address 
(as it is in the previous case). 

When external PDN allocation is used the PDN GW shall act as a DHCPv4 server towards the UE. The PDN GW acts 
as DHCP Client and it interacts with the DHCP server in the external PDN to obtain the IP address and the 
configuration parameters. If RADIUS or Diameter is used towards the external PDN as described in TS 29.061 [38], the 
IP address and the requested configuration parameters can be fetched as part of these procedures. 

Editor's Note: It is EES how the PDN GW releases the IP address that is assigned to the UE. 

5.3.1 .2.5 IPv6 prefix delegation via DHCPv6 

When the PLMN allocates the IPv6 prefix then the PDN GW responsibility is to allocate and release the IPv6 prefixes 
(as it is in the previous case) and the PDN GW shall act as DHCPv6 server and shall create and send the DHCPv6 
responses to the UE. 

When external PDN allocation is used the PDN GW shall act as a DHCPv6 server towards the UE. The PDN GW acts 
as DHCP Client and it interacts with the DHCP server in the external PDN to obtain IPv6 prefix and other parameters 
for the UE. If RADIUS or Diameter is used towards the external PDN as described in TS 29.061 [38], the IPv6 prefix 
can be fetched as part of these procedures. 

Editor's Note: It is EES how the PDN GW releases the IPv6 prefix that is assigned to the UE. 

5.3.2 Attach procedure 
5.3.2.1 E-UTRAN Initial Attach 

A UE/user needs to register with the network to receive services that require registration. This registration is described 
as Network Attachment. The always-on IP connectivity for UE/users of the EPS is enabled by establishing a default 
EPS bearer during Network Attachment. The PCC rules applied to the default EPS bearer may be predefined in the 
PDN GW and activated in the attachment by the PDN GW itself. The Attach procedure may trigger one or multiple 
Dedicated Bearer Establishment procedures to establish dedicated EPS bearer(s) for that UE. During the attach 
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procedure, the UE may request for an IP address allocation. Terminals utilising only IETF based mechanisms for IP 
address allocation are also supported. 

During the Initial Attach procedure the Mobile Equipment Identity may be obtained from the UE. The MME operator 
may check the ME Identity with an EIR. At least in roaming situations, the MME should pass the ME Identity to the 
HSS, and, if a PDN-GW outside of the VPLMN, should pass the ME Identity to the PDN-GW. 
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Figure 5.3.2.1-1: Attach procedure 
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NOTE 1: For a PMIP-based S5/S8, procedure steps (A), (B), and (C) are defined in TS 23.402 [2]. Steps 7, 10, 14, 
15 and 16 concern GTP based S5/S8. 

NOTE 2: The Serving GWs and PDN GWs involved in steps 7 and/or 10 may be to different to those in 
steps 13-17. 

1 . The UE initiates the Attach procedure by the transmission of an Attach Request (IMSI or old GUTI, last visited 
TAI (if available), UE Network Capability, PDN Type, Protocol Configuration Options, Ciphered Protocol 
Configuration Options Transfer, Attach Type, KSI, NAS sequence number, NAS-MAC) message together with 
an indication of the Selected Network to the eNodeB. IMSI shall be included if the UE does not have a valid 
GUTI available. If the UE has a valid GUTI, it shall be included. If available, the last visited TAI shall be 
included in order to help the MME produce a good list of TAIs for any subsequent Attach Accept message. 
Selected Network indicates the PLMN that is selected for network sharing purposes. UE Network Capability is 
described in clause "UE capabilities". If the UE has valid security parameters, the Attach Request message shall 
be integrity protected by the NAS-MAC in order to allow validation of the UE by the MME. KSI is included if 
the UE has valid security parameters. NAS sequence number indicates the sequential number of the NAS 
message. Furthermore, the UE may cipher the parts of the Attach Request message that require ciphering (it is 
FES whether there are any such parts). If the UE does not have a valid NAS security association, then the Attach 
Request message is neither integrity protected nor ciphered. In this case the security association is established in 
step 5a. The UE network capabilities indicate also the supported NAS and AS security algorithms. PDN type 
indicates the requested IP version (IPv4, IPv4/IPv6, IPv6). Protocol Configuration Options (PCO) are used to 
transfer parameters between the UE and the PDN GW, and are sent transparently through the MME and the 
Serving GW. The Protocol Configuration Options may include the Address Allocation Preference indicating that 
the UE prefers to obtain an IPv4 address only after the default bearer activation by means of DHCPv4. If the UE 
intends to send PCOs, which require ciphering (e.g., PAP/CHAP usernames and passwords), the UE shall set the 
Ciphered Protocol Configuration Options Transfer (Ciphered PCO Transfer) flag and shall send all PCOs only 
after authentication and NAS security setup have been completed (see below). Attach Type indicates "Handover" 
when the UE has already an activated PDN GW/HA due to mobility with non-3 GPP accesses. 

Editor's note: It's assumed that all the radio capabilities of the UE that the eNodeB has to know in order to handle 
radio resources for this UE are send to eNodeB upon RRC connection establishment. 

2. The eNodeB derives the MME from the GUTI and from the indicated Selected Network. If that MME is not 
associated with the eNodeB, the eNodeB selects an MME as described in clause 4.3.8.3 on "MME selection 
function". The eNodeB forwards the Attach Request message to the new MME contained in a SI -MME control 
message (Initial UE message) together with the Selected Network and an indication of the E-UTRAN Area 
identity, a globally unique E-UTRAN ID of the cell from where it received the message to the new MME. 

3. If the UE identifies itself with GUTI and the MME has changed since detach, the new MME sends an 
Identification Request (old GUTI, complete Attach Request message) to the old MME to request the IMSI. If the 
S-TMSI and old TAI identifies an SGSN, the message shall be sent to the old SGSN. The old MME responds 
with Identification Response (IMSI, unused EPS Authentication Vectors, KSIasme, Kasme) and if request is 
sent to the old SGSN, then the old SGSN responds with Identification Response(IMSI, Unused Authentication 
Quintets, CK, IK and KSI). If the UE is not known in the old MME/SGSN or if the integrity check for the Attach 
Request message fails, the old MME/SGSN responds with an appropriate error cause. 

NOTE: A Pre-Rel-8 SGSN always responds with the UMTS security parameters and the MME may cache it for 
later use. 

4. If the UE is unknown in both the old MME/SGSN and new MME, the new MME sends an Identity Request to 
the UE to request the IMSI. The UE responds with Identity Response (IMSI). 

5a If no UE context for the UE exists anywhere in the network, if the Attach Request (sent in step 1) was not 
integrity protected, or if the check of the integrity failed, then authentication and NAS security setup are 
mandatory. Otherwise it is optional. The authentication and NAS security setup functions are defined in 
clause 5.3.10 on "Security Function". 

5b. The ME Identity shall be retrieved from the UE at Initial Attach when Attach Type does not indicate handover. 
Otherwise it is optional. The ME identity shall be transferred encrypted. The MME may send the ME Identity 
Check Request (ME Identity, IMSI) to the FIR. The FIR shall respond with ME Identity Check Ack (Result). 
Dependent upon the Result, the MME decides whether to continue with this Attach procedure or to reject the 
UE. 
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Editor's note: It is FFS whether NAS security setup and ME identity retrieval can be combined in the case when 
both procedures are to be performed. 

6. If the UE has set the Ciphered PCO Transfer flag in the Attach Request message, the Protocol Configuration 
Options shall now be retrieved from the UE. 

7. If there are active bearer contexts in the new MME for this particular UE (i.e. the UE re-attaches to the same 
MME without having properly detached before), the new MME deletes these bearer contexts by sending Delete 
Bearer Request (TEIDs) messages to the GWs involved. The GWs acknowledge with Delete Bearer Response 
(TEIDs) message. If a PCRF is deployed, the PDN GW employs an IP-CAN Session Termination procedure to 
indicate that resources have been released. 

8. If the MME has changed since the last detach, or if there is no valid subscription context for the UE in the MME, 
or if the ME identity has changed, the MMEsends an Update Location (MME Identity, IMSI, ME Identity) to the 
HSS. 

9. The HSS sends Cancel Location (IMSI, Cancellation Type) to the old MME with Cancellation Type set to 
Update Procedure. The old MME acknowledges with Cancel Location Ack (IMSI) and removes the MM and 
bearer contexts. 

10. If there are active bearer contexts in the old MME for this particular UE, the old MME deletes these bearer 
contexts by sending Delete Bearer Request (TEIDs) messages to the GWs involved. The GWs return Delete 
Bearer Response (TEIDs) message to the old MME. If a PCRF is deployed, the PDN GW employs an IP-CAN 
Session Termination procedure as defined in TS 23.203 [6] to indicate that resources have been released. 

1 1. The HSS sends Insert Subscriber Data (IMSI, Subscription Data) message to the new MME. The Subscription 
Data contain one or more PDN subscription contexts. Each PDN subscription context contains an'EPS 
subscribed QoS profile' (see clause 4.7.3). The MME adopts the PDN subscription context that is marked as 
default for the default bearer activation, which is performed during this attach procedure. This results in the 
usage of the Default APN for this procedure. The new MME validates the UE's presence in the (new) TA. If due 
to regional subscription restrictions or access restrictions the UE is not allowed to attach in the TA, the new 
MME rejects the Attach Request with an appropriate cause, and may return an Insert Subscriber Data Ack 
message to the HSS. If subscription checking fails for other reasons, the new MME rejects the Attach Request 
with an appropriate cause and returns an Insert Subscriber Data Ack message to the HSS including an error 
cause. If all checks are successful then the new MME constructs a context for the UE and returns an Insert 
Subscriber Data Ack message to the HSS. 

12. The HSS acknowledges the Update Location message by sending an Update Location Ack to the new MME. If 
the Update Location is rejected by the HSS, the new MME rejects the Attach Request from the UE with an 
appropriate cause. 

13. If a subscribed PDN address is allocated for the UE for this APN, the PDN subscription context contains the 
UE's IPv4 address and/or the IPv6 prefix and optionally the PDN GW identity. In case the PDN subscription 
context contains a subscribed IPv4 address and/or IPv6 prefix, the MME indicates it in the PDN address. If the 
PDN subscription context contains no PDN GW identity the new MME selects a PDN GW as described in 
clause 4.3.8.1 on PDN GW selection function (3GPP accesses). If the PDN subscription context contains a 
dynamically allocated PDN GW identity and the Attach Type does not indicate "Handover" the MME may select 
a new PDN GW as described in clause PDN GW selection function, e.g. to allocate a PDN GW that allows for 
more efficient routing. If the PDN subscription profile contains no PDN GW address for the default PDN and the 
Attach Type indicates "Handover" the MME select a new PDN GW as described in clause PDN GW selection 
function. The new MME selects a Serving GW as described in clause 4.3.8.2 on Serving GW selection function 
and allocates an EPS Bearer Identity for the Default Bearer associated with the UE. Then it sends a Create 
Default Bearer Request (IMSI, MSISDN, MME TEID for control plane, PDN GW address, PDN Address, APN, 
RAT type. Default Bearer QoS, PDN Type, APN-AMBR, EPS Bearer Identity, Protocol Configuration Options, 
ME Identity, User Location Information (ECGI), Selection Mode, Charging Characteristics, Trace Reference, 
Trace Type, Trigger Id, OMC Identity, Maximum APN Restriction, Dual Address Bearer Flag, the Protocol 
Type over S5/S8) message to the selected Serving GW. 

The RAT type is provided in this message for the later PCC decision. The AMBR applied to the relevant PDN 
access is also provided in this message. The MSISDN is included if provided in the subscription data from the 
HSS. Selection Mode indicates whether a subscribed APN was selected, or whether a non-subscribed APN 
chosen by the MME was selected. Selection Mode is set according to Annex A of TS 23.060 [7]. The P-GW may 
use Selection Mode when deciding whether to accept or reject the default bearer activation. For example, if an 
APN requires subscription, the P-GW is configured to accept only the default bearer activation that requests a 
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subscribed APN as indicated by Selection Mode. Charging Characteristics indicates which kind of charging the 
bearer context is Hable for. The Dual Address Bearer Flag shall be set when the UE requests PDN type IPv4v6 
and all SGSNs which the UE may be handed over to are Release 8 or above supporting dual addressing, which is 
determined based on node pre-configuration by the operator. The Protocol Type over S5/S8 is provided to 
Serving GW which protocol should be used over S5/S8 interface. 

The charging characteristics for the PS subscription and individually subscribed APNs as well as the way of 
handling Charging Characteristics and whether to send them or not to the P-GW is defined in TS 32.251 [44]. 
The MME shall include Trace Reference, Trace Type, Trigger Id, and OMC Identity if S-GW and/or P-GW trace 
is activated. The MME shall copy Trace Reference, Trace Type, and OMC Identity from the trace information 
received from the HLR or OMC. 

The Maximum APN Restriction denotes the most stringent restriction as required by any already active bearer 
context. If there are no already active bearer contexts, this value is set to the least restrictive type (see clause 15.4 
of TS 23.060 [7]). If the P-GW receives the Maximum APN Restriction, then the P-GW shall check if the 
Maximum APN Restriction value does not conflict with the APN Restriction value associated with this bearer 
context request. If there is no conflict the request shall be allowed, otherwise the request shall be rejected with 
sending an appropriate error cause to the UE. 

14. The Serving GW creates a new entry in its EPS Bearer table and sends a Create Default Bearer Request (IMSI, 
MSISDN, APN, Serving GW Address for the user plane. Serving GW TEID of the user plane. Serving GW 
TEID of the control plane, RAT type. Default Bearer QoS, PDN Type, PDN Address, APN-AMBR, EPS Bearer 
Identity, Protocol Configuration Options, ME Identity, User Location Information (ECGI), Selection Mode, 
Charging Characteristics, Trace Reference, Trace Type, Trigger Id, OMC Identity, Maximum APN Restriction, 
Dual Address Bearer Flag) message to the PDN GW indicated by the PDN GW address received in the previous 
step. After this step, the Serving GW buffers any downlink packets it may receive from the PDN GW until 
receives the message in step 21 below. The MSISDN is included if received from the MME. 

15. If dynamic PCC is deployed, the PDN GW performs an IP-CAN Session Establishment procedure as defined in 
TS 23.203 [6], and thereby obtains the default PCC rules for the UE. This may lead to the establishment of a 
number of dedicated bearers following the procedures defined in clause 5.4.1 in association with the 
establishment of the default bearer, which is described in Annex F. 

The IMSI, UE IP address. User Location Information (ECGI), Serving Network, RAT type, APN-AMBR, 
Default Bearer QoS are provided to the PCRF by the PDN GW if received by the previous message. The User 
Location Information is used for location based charging. 

NOTE: While the PDN GW/PCEF may be configured to activate predefined PCC rules for the default bearer, the 
interaction with the PCRF is still required to provide e.g. the UE IP address information to the PCRF. 

If dynamic PCC is not deployed, the PDN GW may apply local QoS policy. 

Editor's note: It is FES if the AMBR shall be sent to the PCRF, and if the PCRF is allowed to change the value of 
the AMBR. 

Editor's note: The parameters used for User Location Information are FES. 

16. The P-GW creates a new entry in its EPS bearer context table and generates a Charging Id. The new entry allows 
the P-GW to route user plane PDUs between the S-GW and the packet data network, and to start charging. The 
way the P-GW handles Charging Characteristics that it may have received is defined in TS 32.251 [44]. 
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The PDN GW returns a Create Default Bearer Response (PDN GW Address for the user plane, PDN GW TEID 
of the user plane, PDN GW TEID of the control plane, PDN Type, PDN Address, EPS Bearer Identity, Protocol 
Configuration Options, UL TFT, Charging Id, Prohibit Payload Compression, APN Restriction, Cause, 
CGI/SAI/RAI change report required, BCM) message to the Serving GW. The PDN GW takes into account the 
PDN type sent by the UE , the Dual Address Bearer Flag and the policies of operator when the PDN GW selects 
the PDN type to be used as follows. If the UE has requested PDN type IPv4v6 and both IPv4 and IPv6 
addressing is possible in the PDN but the Dual Address Bearer Flag is not set, or only single IP version 
addressing is possible in the PDN, the PDN GW selects a single IP version (either IPv4 or IPv6). If the UE has 
requested PDN type IPv4 or IPv6, the PDN GW uses the PDN type supplied by the UE in case it is supported in 
the PDN, otherwise an appropriate error cause will be returned. The PDN GW allocates a PDN Address 
according to the selected PDN type. In case the PDN GW has selected a PDN type different from the one sent by 
the UE, the PDN GW indicates together with the PDN type IE a reason cause (network preference, single 
address bearers only) to the UE why the PDN type has been modified. PDN Address may contain an IPv4 
address for IPv4 and/or an IPv6 prefix and an Interface Identifier. If the PDN has been configured by the 
operator so that the PDN addresses for the requested APN shall be allocated by usage of DHCPv4 only, or if the 
PDN GW allows the UE to use DHCPv4 for address allocation according to the Address Allocation Preference 
received from the UE, the PDN Address shall be set to 0.0.0.0, indicating that the IPv4 PDN address shall be 
negotiated by the UE with DHCPv4 after completion of the Default Bearer Activation procedure. In case of 
external PDN addressing for IPv6, the PDN GW obtains the IPv6 prefix from the external PDN using either 
RADIUS or Diameter client function. In the PDN Address field of the Create Default Bearer Response, the PDN 
GW includes the Interface Identifer and IPv6 prefix. The PDN GW sends Router Advertisement to the UE after 
default bearer establishment with the IPv6 prefix information for all cases. 

If the PDN address is contained in the Create Default Bearer Request, the PDN GW shall allocate the IPv4 
addresss and/or IP6 prefix contained in the PDN address to the UE. The IP address allocation details are 
described in clause 5.3.1 on 'TP Address Allocation". Protocol Configuration Options contains the BCM as well 
as optional PDN parameters that the P-GW may transfer to the UE. BCM shall also be sent as a separate IE. 
These optional PDN parameters may be requested by the UE, or may be sent unsolicited by the P-GW. Protocol 
Configuration Options are sent transparently through the MME. According to the used RAT BCM is set to 
"UE/network". 

17. If the CGI/SAI/RAI change report required is received for this bearer context, then the S-GW shall store this for 
the bearer context and the S-GW shall report to that P-GW whenever a CGI/SAI/RAI change occurs that meets 
the P-GW request, as described in clause 15.1.1a of TS 23.060 [7]. 

The Serving GW returns a Create Default Bearer Response (PDN Type, PDN Address, Serving GW address for 
User Plane, Serving GW TEID for User Plane, Serving GW TEID for control plane, EPS Bearer Identity, PDN 
GW addresses and TEIDs (GTP-based S5/S8) or GRE keys (PMIP-based S5/S8) at the PDN GW(s) for uplink 
traffic. Protocol Configuration Options, UL TFT, DL TFT (for PMIP-based S5/S8), Charging Id, Prohibit 
Payload Compression, APN Restriction, Cause, CGI/SAI/RAI change report required, BCM) message to the new 
MME. The DL TFT for PMIP-based S5/S8 is obtained from interaction between the Serving GW and the PCRF 
as described in clause 5.2 of TS 23.402 [2], when PCC is deployed; otherwise, the DL TFT IE is wildcarded, 
matching any downlink traffic. 

18. If an APN Restriction is received, then the MME shall store this value for the Bearer Context and the MME shall 
check this received value with the stored value for the Maximum APN Restriction to ensure there are no 
conflicts between values. If the Bearer Context is accepted, the MME shall determine a (new) value for the 
Maximum APN Restriction. If there is no previously stored value for Maximum APN Restriction, then the 
Maximum APN Restriction shall be set to the value of the received APN Restriction. 

If the CGI/SAI/RAI change report required is received for this bearer context, then the MME shall store this for 
the bearer context and the MME shall report whenever a CGI/SAI/RAI change occurs that meets the request, as 
described in clause 15.1.1a of TS 23.060 [7]. 

The new MME sends an Attach Accept (APN, GUTI, PDN Type, PDN Address, TAI List, EPS Bearer Identity, 
Session Management Configuration IE, Protocol Configuration Options, KSI, NAS sequence number, NAS- 
MAC, NAS security algorithm) message to the eNodeB. GUTI is included if the new MME allocates a new 
GUTI. This message is contained in an S1_MME control message Initial Context Setup Request. This SI control 
message also includes the AS security context information for the UE, the Handover Restriction List, the EPS 
Bearer QoS, the UE-AMBR, EPS Bearer Identity, as well as the TEID at the Serving GW used for user plane 
and the address of the Serving GW for user plane. The MME includes the UL TFT and the EPS Bearer QoS 
parameter QCI into the Session Management Configuration IE. Furthermore, if the UE has UTRAN or GERAN 
capabilities, the MME uses the EPS bearer QoS information to derive the corresponding PDP context parameters 
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QoS Negotiated (R99 QoS profile), Radio Priority and Packet Flow Id and includes them in the Session 
Management Configuration. If the UE indicated in the UE Network Capability it does not support BSS packet 
flow procedures, then the MME shall not include the Packet Flow Id. Handover Restriction List is described in 
clause 4.3.5.7 "Mobility Restrictions". 

NAS security algorithm indicates the NAS algorithm selected by the MME. This information element shall not 
be ciphered. The MME starts using the indicated NAS security algorithm with this NAS message. 

19. The eNodeB sends the RRC Connection Reconfiguration message including the EPS Radio Bearer Identity to 
the UE, and the Attach Accept message will be sent along to the UE. The UE shall store the QoS Negotiated, 
Radio Priority, Packet Flow Id, which it received in the Session Management Configuration, for use when 
accessing via GERAN or UTRAN. The UE shall ignore the IPv6 prefix information in PDN Address. The APN 
is provided to the UE to notify it of the APN for which the activated default bearer is associated. The UE uses 
the uplink packet filter (UL TFT) to determine the mapping of uplink packets to the radio bearer. For further 
details, see TS 36.331 [37]. The UE may provide EPS Bearer QoS information to the application handling the 
service data flow. The application usage of the EPS Bearer QoS is implementation dependent. The UE shall not 
reject the RRC Connection Reconfiguration on the basis of the EPS Bearer QoS information contained in the 
Session Management Configuration IE. 

When receiving the Attach Accept message the UE sets its TIN to "GUTI" as no ISR is indicated. And the UE's 
internal update status for any stored P-TMSI is set to "update-needed". 

NOTE: The IP address allocation details are described in clause 5.3.1 on "IP Address Allocation". 

20. The UE sends the RRC Connection Reconfiguration Complete message to the eNodeB. This message includes 
the Attach Complete (EPS Bearer Identity, NAS sequence number, NAS-MAC) message. For further details, see 
TS 36.331 [37]. With the Attach Complete message the UE starts using the NAS security algorithm indicated by 
the MME, i.e. the Attach Complete message shall be protected by the NAS security algorithm indicated by the 
MME. 

21. The eNodeB forwards the Attach Complete message to the new MME in an SI control message. This SI control 
message includes the TEID of the eNodeB and the address of the eNodeB used for downlink traffic on the S1_U 
reference point. 

After the Attach Accept message and once the UE has obtained a PDN Address, the UE can then send uplink 
packets towards the eNodeB which will then be tunnelled to the Serving GW and PDN GW. If the UE requested 
for a dual address PDN type (IPv4v6) to a given APN and was granted a single address PDN type (IPv4 or IPv6) 
by the network with a reason cause "single address bearers only" sent together with the PDN type, the UE may 
request for the activation of a parallel PDN connection to the same APN with a single address PDN type (IPv4 or 
IPv6) other than the one already activated. If the UE receives no reason cause in step 1 8 in response to an IPv4v6 
PDN type and it receives an IPv6 prefix and Interface Identifier apart from the IPv4 address or 0.0.0.0 in the 
PDN Address field, it considers that the request for a dual address PDN was successful. It can wait for the 
Router Advertisement from the network with the IPv6 prefix information or it may send Router Solicitation if 
necessary. 

22. The new MME sends an Update Bearer Request (eNodeB address, eNodeB TEID) message to the Serving GW. 

23. The Serving GW acknowledges by sending Update Bearer Response (EPS Bearer Identity) message to the new 
MME. The Serving GW can then send its buffered downlink packets. 

24. After the MME receives Update Bearer Response (EPS Bearer Identity) message, if an EPS bearer was 
established and the subscription data indicates that the user is allowed to perform handover to non-3 GPP 
accesses, and if the MME selected a PDN GW that is different from the PDN GW identity which was indicated 
by the HSS in the PDN subscription context, the MME shall send an Update Location Request including the 
APN and PDN GW identity to the HSS for mobility with non-3GPP accesses. 

25. The HSS stores the APN and PDN GW identity pair and sends an Update Location Response to the MME. 



5.3.2.2 UTRAN/GERAN Initial Attach 

When a UE attaches to UTRAN/GERAN, it executes the normal attach procedure as defined in TS 23.060 [7]. When 
the UE needs an IP address, it initiates PDP context activation procedure as defined in TS 23.060 [7]. 
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Editor's note: It is FFS how to handle the case when the UE changes to E-UTRAN access when it only has a PDP 
context over GERAN/UTRAN which maps to a GBR bearer over E-UTRAN. 

5.3.3 Tracking Area Update procedures 

5.3.3.1 Tracking Area Update procedure with Serving GW change 
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Figure 5.3.3.1-1 : Tracking Area Update procedure with Serving GW cliange 
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NOTE 1: For a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Steps 9 and 10 
concern GTP based S5/S8. 



1 . The UE detects a change to a new TA by discovering that its current TAI is not in the list of TAIs that the UE 
registered with the network, or the UE reselects an E-UTRAN cell and is not registered or updated with the 
MME (e.g. periodic TAU timer expired while camping on GERAN or UTRAN) or the UE was in 
PMM_Connected state (e.g. URA_PCH) when it reselects an E-UTRAN cell. 

2. The UE initiates the TAU procedure by sending a TAU Request (old GUTI, last visited TAI, active flag, EPS 
bearer status, P-TMSI Signature, additional GUTI, KSI, NAS sequence number, NAS-MAC) message together 
with an indication of the Selected Network to the eNodeB. 

If the UE's TIN indicates "GUTI" or "RAT-related TMSI" and the UE holds a vaUd GUTI then the old GUTI 
indicates this vaUd GUTI. If the UE's TIN indicates "P-TMSI" and the UE holds a vaHd P-TMSI and related RAI 
then these two elements are indicated as the old GUTI. Mapping a P-TMSI and RAI to a GUTI is specified in 
Annex H. 

If the UE holds a valid GUTI then the UE indicates the GUTI as additional GUTI, regardless whether the old 
GUTI also indicates this GUTI or a GUTI mapped from a P-TMSI. 
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The routing parameter that is signalled in the RRC signalling to the eNB for routing to the MME is derived from 
the identifier that is signalled as the old GUTI according to the rules above. For a combined MME/SGSN the 
eNB is configured to route the MME-code(s) of this combined node to the same combined node. This eNB is 
also configured to route MME-code(s) of GUTIs that are generated by the UE's mapping of the P-TMSIs 
allocated by the combined node. Such an eNB configuration may also be used for separate nodes to avoid 
changing nodes in the pool caused by inter RAT mobility. 

The last visited TAI shall be included in order to help the MME produce a good list of TAIs for any subsequent 
TAU Accept message. Selected Network indicates the network that is selected. Active flag is a request by UE to 
activate the radio and SI bearers for all the active EPS Bearers by the TAU procedure when the UE is in ECM- 
IDLE state. The EPS bearer status that indicates each EPS bearer that is active in the UE. If the UE has valid 
security parameters, the TAU Request message shall be integrity protected by the N AS -MAC in order to allow 
validation of the UE by the MME. KSI is included if the UE has valid security parameters. NAS sequence 
number indicates the sequential number of the NAS message. 

3. The eNodeB derives the MME from the GUTI and from the indicated Selected Network. If that MME is not 
associated with that eNodeB,the eNodeB selects an MME as described in clause 4.3.8.3 on "MME Selection 
Function". 

The eNodeB forwards the TAU Request message together with an indication of the E-UTRAN Area Identity, a 
globally unique E-UTRAN ID, of the cell from where it received the message and with the Selected Network to 
the new MME. 

4. The new MME sends a Context Request (old GUTI, complete TAU Request message) message to the old 
MME/old S4 SGSN to retrieve user information. The new MME/old S4 SGSN derives the old MME from the 
old GUTI. If the new MME indicates that it has authenticated the UE or if the old MME correctly validates the 
UE, then the old MME starts a timer. 

5. The old MME/old S4 SGSN responds with a Context Response (MME context (e.g. IMSI, MSISDN, unused 
EPS Authentication Vectors, KSIasme, Kasme, bearer contexts, Serving GW signalling Address and TEID(s), 
ISR) message. The PDN GW Address and TEID(s) (for GTP-based S5/S8) or GRE Keys (PMIP-based S5/S8 at 
the PDN GW(s) for uplink traffic) is part of the Bearer Context. If the UE is not known in the old MME or if the 
integrity check for the TAU Request message fails, the old MME responds with an appropriate error cause. The 
MSISDN is included if the old MME has it stored for that UE. 

6. If the integrity check of TAU Request message (sent in step 2) failed, then authentication is mandatory. The 
authentication functions are defined in clause 5.3.10 on "Security Function". Ciphering procedures are described 
in clause 5.3.10 on "Security Function". If GUTI allocation is going to be done and the network supports 
ciphering, the NAS messages shall be ciphered. 

7. The new MME determines whether to relocate the Serving GW or not. The Serving GW is relocated when the 
old Serving GW cannot continue to serve the UE. The new MME may also decide to relocate the Serving GW in 
case a new Serving GW is expected to serve the UE longer and/or with a more optimal UE to PDN GW path, or 
in case a new Serving GW can be co-located with the PDN GW. Selection of a new Serving GW is performed 
according to clause 4.3.8.2 on "Serving GW selection function". 

The new MME sends a Context Acknowledge (Serving GW change indication) message to the old MME/old S4 
SGSN. Serving GW change indication indicates a new Serving GW has been selected. The old MME/old S4 
SGSN marks in its context that the information in the GWs and the HSS are invalid. This ensures that the old 
MME/old S4 SGSN updates the GWs and the HSS if the UE initiates a TAU procedure back to the old MME/old 
S4 SGSN before completing the ongoing TAU procedure. If the security functions do not authenticate the UE 
correctly, then the TAU shall be rejected, and the new MME shall send a reject indication to the old MME/old 
S4 SGSN. The old MME/old S4 SGSN shall continue as if the Identification and Context Request was never 
received. 

ISR is not indicated in the Context Acknowledge as ISR is not activated due to the S-GW change. 

8. The MME constructs an MM context for the UE. The MME verifies the EPS bearer status received from the UE 
with the bearer contexts received from the old MME/old S4 SGSN and releases any network resources related to 
EPS bearers that are not active in the UE. If there is no bearer context suitable for default bearer or no bearer 
context at all, the MME rejects the TAU Request. If the new MME selected a new Serving GW it sends a Create 
Bearer Request (IMSI, bearer contexts, MME Context ID, Type, the Protocol Type over S5/S8) message to the 
selected new Serving GW. The PDN GW address and DL TFT (for PMIP-based S5/S8) are indicated in the 
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bearer Contexts. Type indicates to the Serving GW to send the Update Bearer Request the PDN GW. The 
Protocol Type over S5/S8 is provided to Serving GW which protocol should be used over S5/S8 interface. 

Editor's note: It is FFS whether a TAU Accept can be done instead with an indication that default bearer is not 
established. 

9. The new Serving GW sends the message Update Bearer Request (Serving GW Address, Serving GW Tunnel 
Endpoint Identifier) to the PDN GW concerned. 

10. The PDN GW updates its bearer contexts and returns an Update Bearer Response (MSISDN, PDN GW address 
and TEID(s)) message. The MSISDN is included if the PDN GW has it stored in its UE context. 

1 1 . The Serving GW updates its bearer context. This allows the Serving GW to route bearer PDUs to the PDN GW 
when received from eNodeB. 

The Serving GW returns a Create Bearer Response (MME Context ID, Serving GW address and TEID for user 
plane. Serving GW Context ID) message to the new MME. 

12. The new MME verifies whether it holds subscription data for the UE identified by the GUTI, the additional 
GUTI or by the IMSI received with the context data from the old CN node. If there are no subscription data in 
the new MME for this UE then the new MME sends an Update Location (MME Identity, IMSI, Update Type) 
message to the HSS. Update Type indicates that only the MME registration shall be updated in HSS. Update 
Type indicates whether HSS should cancel location to the other RAT as well. 

13. The HSS sends the message Cancel Location (IMSI, Cancellation Type) to the old MME with Cancellation Type 
set to Update Procedure. 

14. If the timer started in step 4 is not running, the old MME removes the MM context. Otherwise, the contexts are 
removed when the timer expires. It also ensures that the MM context is kept in the old MME for the case the UE 
initiates another TAU procedure before completing the ongoing TAU procedure to the new MME. The old MME 
acknowledges with the message Cancel Location Ack (IMSI). 

15. The HSS sends Insert Subscriber Data (IMSI, Subscription Data) to the new MME. The new MME vahdates the 
UE's presence in the (new) TA. If due to regional subscription restrictions or access restrictions the UE is not 
allowed to be attached in the TA, the MME rejects the Tracking Area Update Request with an appropriate cause 
to the UE, and may return an Insert Subscriber Data Ack (IMSI, MME Area Restricted) message to the HSS. If 
all checks are successful, the MME constructs an MM context for the UE and returns an Insert Subscriber Data 
Ack (IMSI) message to the HSS. 

16. The HSS acknowledges the Update Location message by sending an Update Location Ack to the new MME. If 
the Update Location is rejected by the HSS, the new MME rejects the Attach Request from the UE with an 
appropriate cause. 

17. When the timer started in step 4 expires the old MME/old S4 SGSN releases any local MME or SGSN bearer 
resources and if it received the Serving GW change indication in the Context Acknowledge message, the old 
MME/old S4 SGSN deletes the EPS bearer resources by sending Delete Bearer Request (Cause, TEID) messages 
to the Serving GW. Cause indicates to the old Serving GW that the old Serving GW shall not initiate a delete 
procedure towards the PDN GW. If ISR is established on the S-GW then the S-GW deletes the bearer resources 
on the other old CN node by sending Delete Bearer Request message(s) to that CN node. If the MME has not 
changed, step 1 1 triggers the release of EPS bearer resources when a new Serving GW is allocated. 

18. The Serving GW acknowledges with Delete Bearer Response (TEID) messages. 

19. The MME sends a TAU Accept (GUTI, TAI Hst, EPS bearer status, KSI, NAS sequence number, NAS-MAC, 
NAS security algorithm) message to the UE. If the active flag is set the MME may provide the eNodeB with 
Handover Restriction List. GUTI is included if the MME allocates a new GUTI. If the "active flag" is set in the 
TAU Request message the user plane setup procedure can be activated in conjunction with the TAU Accept 
message. The procedure is described in detail in TS 36.300 [5]. The message sequence should be the same as for 
the UE triggered Service Request procedure specified in clause 5.3.4.1 from the step when MME establishes the 
bearer(s). The MME indicates the EPS bearer status IE to the UE. The UE removes any internal resources related 
to bearers that are not marked active in the received EPS bearer status. Handover Restriction List is described in 
clause 4.3.5.7 "Mobility Restrictions". 

NAS security algorithm indicates the NAS algorithm selected by the MME. This information element shall not 
be ciphered. The MME starts using the indicated NAS security algorithm with this NAS message 
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When receiving the TAU Accept message and there is no ISR indication the UE sets its TIN to "GUTI". When 
ISR is not indicated the UE clears any internal ISR status by setting its internal update status for the P-TMSI to 
"update-needed". 

For a S-GW change, ISR is never indicated by the MME as it needs a RAU with the same S-GW first to activate 
ISR. In case of an MME change ISR is not activated by the new MME to avoid context transfer procedures with 
two old CN nodes. 

20. If GUTI or NAS security algorithm was included in the TAU Accept, the UE acknowledges the received 
message by returning a TAU Complete message to the MME. If NAS security algorithm was included in the 
TAU Accept, the NAS sequence number and NAS-MAC message shall be included in the TAU Complete. With 
the TAU Complete message the UE starts using the NAS security algorithm indicated by the MME, i.e. the TAU 
Complete message shall be protected by the NAS security algorithm indicated by the MME. 

When the "Active flag" is not set in the TAU Request message and the Tracking Area Update was not initiated 
as the part of the handover, the new MME releases the signalling connection with UE, according to clause 5.3.5. 

NOTE 2: The new MME may initiate RAB establishment after execution of the security functions, or wait until 

completion of the TA update procedure. For the UE, RAB establishment may occur anytime after the TA 
update request is sent. 

In the case of a rejected tracking area update operation, due to regional subscription, roaming restrictions, or access 
restrictions (see TS 23.221 [27] and TS 23.008 [28]) the new MME shall not construct a bearer context. A reject shall 
be returned to the UE with an appropriate cause and the S 1 connection shall be released. Upon return to idle, the UE 
shall act according to TS 23.122 [10]. 

The new MME shall determine the Maximum APN restriction based on the received APN Restriction of each bearer 
context from the P-GW and then store the new Maximum APN restriction value. 

If the new MME is unable to support the same number of active bearer contexts as received from old SGSN, the new 
MME should use the prioritisation sent by the old SGSN as input when deciding which bearer contexts to maintain 
active and which ones to delete. In any case, the new MME shall first update all contexts in one or more P-GWs and 
then deactivate the context(s) that it cannot maintain as described in the clause "MME Initiated Dedicated Bearer 
Deactivation Procedure". This shall not cause the MME to reject the tracking area update. 

NOTE 3: In case MS (UE) was in PMM-CONNECTED state the bearer contexts are sent already in the Forward 
Relocation Request message as described in the clause "Serving RNS relocation procedures" of 
TS 23.060 [7]. 

If the tracking area update procedure fails a maximum allowable number of times, or if the MME returns a Tracking 
Area Update Reject (Cause) message, the UE shall enter EMM DEREGISTERED state. 

5.3.3.2 E-UTRAN Tracking Area Update without SGW Change 

The Tracking Area Update procedure takes place when a UE that is registered with an MME and/or a SGSN selects an 
E-UTRAN cell. The procedure is initiated by the UE if the UE changes thereby to a Tracking Area that the UE has not 
yet registered with the network or if the P-TMSI update status is "not updated" due to bearer configuration 
modifications performed between UE and SGSN when ISR is activated. This procedure is initiated by an ECM-IDLE 
state UE and may also be initiated if the UE is in ECM-CONNECTED state. The procedure also takes place when a UE 
registered with a 3G-SGSN in PMM_CONNECTED state selects an E-UTRAN cell regardless whether ISR is 
activated. The cell selection for UTRAN is described in TS 25.304 [12] and TS 25.331 [33]. 

Editor's note: The URA-PCH handling needs to be shown in the steps below. 

This TA update case is illustrated in Figure 5.3.3.2-1. 
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Figure 5.3.3.2-1 : E-UTRAN Tracking Area Update without SGW change 

NOTE 1: For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402 [2]. Steps 12 and 14 concern OTP 
based S5/S8. 

1. The UE selects an E-UTRAN cell of a Tracking Area which is not in the UE's list of TAI's that the UE registered 
with the network, or the UE reselects an E-UTRAN cell and is not registered or updated with the MME (e.g. 
periodic TAU timer expired while camping on GERAN or UTRAN) or the UE was in PMM_Connected state 
(e.g. URA_PCH) when it reselects an E-UTRAN cell. 
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2. The UE initiates a TAU procedure by sending a Tracking Area Update Request (UE Network Capability, active 
flag, EPS bearer status, old GUTI, last visited TAI, P-TMSI signature, additional GUTI) message together with 
an indication of the Selected Network to the eNodeB. 

If the UE's TIN indicates "GUTI" or "RAT-related TMSI" and the UE holds a vaUd GUTI then the old GUTI 
indicates this vaUd GUTI. If the UE's TIN indicates "P-TMSI" and the UE holds a vaUd P-TMSI and related RAI 
then these two elements are indicated as the old GUTI. Mapping a P-TMSI and RAI to a GUTI is specified in 
Annex H. 

If the UE holds a valid GUTI then the UE indicates the GUTI as additional GUTI, regardless whether the old 
GUTI also indicates this GUTI or a GUTI mapped from a P-TMSI. 

The routeing parameter that is signalled in the RRC signalling to the eNB for routing to the MME is derived 
from the identifier that is signalled as the old GUTI according to the rules above. For a combined MME/SGSN 
the eNB is configured to route the MME-code(s) of this combined node to the same combined node. This eNB is 
also configured to route MME-code(s) of GUTIs that are generated the UE's mapping of the P-TMSIs allocated 
by the combined node. Such an eNB configuration may also be used for separate nodes to avoid changing nodes 
in the pool caused by inter RAT mobility. 

The last visited TAI shall be included in order to help the MME produce a good list of TAIs for any subsequent 
TAU Accept message. Selected Network indicates the network that is selected. Active flag is a request by the 
UE to activate the radio and SI bearers for all the active EPS Bearers by the TAU procedure. The UE's ISR 
capability is included in the UE Network Capability element. 

3. The eNodeB derives the MME from the old GUMMEI (contained within the old GUTI) and the indicated 
Selected Network. If that GUMMEI is not associated with the eNodeB, or the GUMMEI is not available, the 
eNodeB selects the MME as described in clause 4.3.8.3 on "MME Selection Function". The eNodeB forwards 
the TAU Request message together with the ECGI of the cell from where it received the message and with the 
Selected Network to the MME. 

Editor's Note: It is FES how the S-TMSI and P-TMSI handling is performed to let RAN select the same CN node for 
GERAN/UTRAN access as for E-UTRAN access, this to support co-location of the MME function and 
the SGSN function in one node. 

Editor's Note: It is FES whether and how an S-TMSI is derived from the P-TMSI. It is also FES whether this 
facilitates the collocated MME/SGSN or whether additional information is used for this. 

4. If the UE provided an old GUTI, that identifies an old MME, the new MME sends a Context Request (old GUTI, 
MME Address, UE Validated, complete TAU Request message) message to the old MME to retrieve the user 
information. The MME derives the old MME from the old GUTI. If the new MME indicates that it has 
authenticated the UE or if the old MME authenticates the UE, the old MME starts a timer. 

5. The old MME responds with a Context Response (Context) message. Bearer contexts, PDN GW Address, and 
Serving GW Address are part of the Context. The Bearer contexts shall be sent in a prioritized order, i.e. the 
most important Bearer context first. The prioritization method is implementation dependent, but should be based 
on the current activity. 

NOTE 2: Assigning the highest priority to the Bearer context without TFT could be done to get service continuity 
for all ongoing services regardless of the number of supported EPS bearers in the UE and network. 

The new MME shall ignore the UE Network Capability contained in the Context of Context Response only when 
it has previously received an UE Network Capability in the Tracking Area Update Request. If the UE is not 
known in the old MME or if the integrity check for the TAU request message fails, the old MME responds with 
an appropriate error cause. 

6. If the UE provided an old GUTI that identifies an old SGSN, or the UE provided an old GUTI that identifies an 
old SGSN, then the new MME sends a Context Request (old GUTI, UE VaUdated, MME Address, P-TMSI 
signature) message to the old SGSN to retrieve the user information. The new MME derives the old SGSN from 
the old GUTI. The new MME always supports the related functionality for Intra Domain Connection of RAN 
Nodes to Multiple CN Nodes. P-TMSI Signature is used by the SGSN for integrity check. UE VaUdated 
indicates that the new MME has authenticated the UE. If the new MME indicates that it has authenticated the UE 
or if the old SGSN authenticates the UE, the old SGSN starts a timer. 
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7. The old SGSN responds with a Context Response (MM context (e.g. IMSI, unused Authentication Quintets, CK, 
IK, KSI, bearer contexts. Serving GW signalHng Address and TEID(s), ISR) message. PDN GW Address and 
Serving GW Address are part of the bearer contexts. If the UE is not known in the old SGSN, the old SGSN 
responds with an appropriate error cause. ISR indicates that the old SGSN is capable to establish ISR for the UE. 
The bearer contexts shall be sent in a prioritized order, i.e. the most important bearer context first. The 
prioritization method is implementation dependent, but should be based on the current activity. The new MME 
shall ignore the UE Network Capability contained in MM Context of Context Response when it has previously 
received an UE Network Capability in the Tracking Area Request. 

NOTE 3: Assigning the highest priority to the bearer context without TFT could be done to get service continuity 
for all ongoing services regardless of the number of supported EPS bearers in the UE and network. 

8. Security functions may be executed. Procedures are defined in clause 5.3.10 on "Security Function". 

9. The MME sends a Context Acknowledge message to the old MME. The old MME marks in its context that the 
information in the GWs and the HSS are invalid. This ensures that the MME updates the GWs and the HSS if the 
UE initiates a TAU procedure back to the MME before completing the ongoing TAU procedure. 

If the security functions do not authenticate the UE correctly, then the TAU shall be rejected, and the MME shall 
send a reject indication to the old MME. The old MME shall continue as if the Identification and Context 
Request was never received. 

10. The MME sends a Context Acknowledge (ISR) message to the old SGSN. Unless ISR is indicated by the MME 
the old SGSN marks in its context that the information in the GWs and the HSS are invalid. This ensures that the 
SGSN updates the GWs and the HSS if the UE initiates a RAU procedure back to the SGSN before completing 
the ongoing TAU procedure. ISR indicates to the old SGSN that it shall maintain the UE's contexts and the 
SGSN stops the timer started in step 6. When ISR is not indicated and this timer expires the old SGSN deletes all 
bearer resources of that UE. As the Context Acknowledge from the MME does not include any S-GW change 
the SGSN does not send any Delete Bearer Request message to the S-GW. 

If the security functions do not authenticate the UE correctly, then the TAU shall be rejected, and the MME shall 
send a reject indication to the old SGSN. The old SGSN shall continue as if the Identification and Context 
Request was never received. 

10b. Forwarding occurs if applicable. 

Editor's note: It is FES if data forwarding needs to be avoided for this procedure. 

1 1. The new MME adopts the bearer contexts received from the old MME/SGSN as the UE's EPS bearer contexts to 
be maintained by the new MME. If necessary, the new MME maps PDP contexts to the EPS bearers 1-to-l and 
maps the pre-Rel-8 QoS parameter values of a PDP context to the EPS QoS parameter values of an EPS bearer 
as defined in Annex E. The MME establishes the EPS bearer(s) in the indicated order. The MME deactivates the 
EPS bearers which cannot be established. 

The new MME verifies the EPS bearer status received from the UE with the EPS bearer contexts it maintains 
and releases any network resources related to EPS bearers that are not active in the UE. If there is no bearer 
context suitable for default bearer or no bearer context at all, the MME rejects the TAU Request. The new MME 
sends an Update Bearer Request (new MME address and TEID, QoS Negotiated, Serving network identity, ISR) 
message to the Serving GW. The PDN GW address is indicated in the bearer contexts. The information element 
ISR indicates whether ISR is established. 

When the Update Bearer Request does not indicate ISR the S-GW deletes any ISR resources by sending a Delete 
Bearer Request to the other CN node that has bearer resources on the S-GW reserved. 

Editor's note: It is EES whether a TAU Accept can be done instead with an indication that default bearer is not 
established. 

12. The Serving GW informs the PDN GW(s) about the change of for example the RAT type that e.g. can be used 
for charging, by sending the message Update Bearer Request (Serving GW Address and TEID, RAT type) to the 
PDN GW(s) concerned. 

13. If dynamic PCC is deployed, and RAT type information needs to be conveyed from the PDN GW to the PCRF, 
then the PDN GW shall send RAT type information to the PCRF by means of an IP-CAN Session Modification 
procedure as defined in TS 23.203 [6]. 
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NOTE 4: The PDN GW does not need to wait for the PCRF response, but continues in the next step. If the PCRF 
response leads to an EPS bearer modification the PDN GW should initiate a bearer update procedure. 

14. The PDN GW updates its context field to allow DL PDUs to be routed to the correct Serving GW. PDN GW 
returns an Update Bearer Response (PDN GW address and TEID, MSISDN) to the Serving GW. The MSISDN 
is included if the PDN GW has it stored in its UE context. 

15. The Serving GW updates its bearer context. This allows the Serving GW to route Bearer PDUs to the PDN GW 
when received from eNodeB. The Serving GW returns an Update Bearer Response (Serving GW address and 
TEID and TEIDs (for GTP-based S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN GW(s) for uplink 
traffic) message to the new MME. 

Editor's note: It is FES whether the same SGW address and TEIDs are used for S4 and SI or whether separate 
parameters are needed. 

16. The new MME verifies whether it holds subscription data for the UE identified by the GUTI, the additional 
GUTI or by the IMSI received with the context data from the old CN node. If there are no subscription data in 
the new MME for this UE then the new MME informs the HSS of the change of MME by sending an Update 
Location (MME Id, IMSI, Update Type) message to the HSS. Update Type indicates that only the MME 
registration shall be updated in HSS. 

17. The HSS sends a Cancel Location (IMSI, Cancellation type) message to the old MME with a Cancellation Type 
set to Update Procedure. 

18. When receiving the Context Acknowledge message and if the UE is lu Connected, the old SGSN sends an lu 
Release Command message to the RNC. 

19. The RNC responds with an lu Release Complete message. 

20. When receiving a Cancel Location message and the timer started in step 4 is not running, the old MME removes 
the MM and bearer contexts. Otherwise, the contexts are removed when the timer expires. It also ensures that the 
MM context is kept in the old MME for the case the UE initiates another TAU procedure before completing the 
ongoing TAU procedure to the new MME. The old MME acknowledges with a Cancel Location Ack (IMSI) 
message. 

NOTE 5: ISR is never indicated from new to old MME. 

So an old MME deletes all bearer resources of an UE in any case when the timer started in step 4 expires, which 
is independent from receiving a Cancel Location message. 

21. The HSS sends Insert Subscriber Data (IMSI, Subscription Data) to the new MME. The new MME validates the 
UE's presence in the (new) TA. If due to regional subscription restrictions or access restrictions the UE is not 
allowed to be attached in the TA, the MME rejects the Tracking Area Update Request with an appropriate cause 
to the UE, and may return an Insert Subscriber Data Ack (IMSI, MME Area Restricted) message to the HSS. If 
all checks are successful, the MME constructs an MM context for the UE and returns an Insert Subscriber Data 
Ack (IMSI) message to the HSS. 

22. The HSS acknowledges the Update Location by returning an Update Location Ack (IMSI) message to the new 
MME after the cancelling of the old MME context is finished. If the Update Location is rejected by the HSS, the 
MME rejects the TAU Request from the UE with an appropriate cause sent in the TAU Reject message to the 
UE. 

23. The new MME responds to the UE with a Tracking Area Update Accept (GUTI, TAI-list, EPS bearer status, 
ISR) message. If the active flag is set the Handover Restriction List may be sent to eNodeB as eNodeB handles 
the roaming restrictions and access restrictions in the Intra E-UTRAN case. If the "active flag" is set in the TAU 
Request message the user plane setup procedure is activated in conjunction with the TAU Accept message. The 
procedure is described in detail in TS 36.300 [5]. The message sequence should be the same as for the UE 
triggered Service Request procedure specified in clause 5.3.4.1 from the step when MME establish the 
bearers(s). The EPS bearer status indicates the active bearers in the network. The UE removes any internal 
resources related to bearers not marked active in the received EPS bearer status. ISR indicates to the UE that its 
P-TMSI and RAI remain registered with the network and remain valid in the UE. If ISR is not indicated the UE 
sets in its internal data the update status of the P-TMSI to "update-needed". Handover Restriction List is 
described in clause 4.3.5.7 "Mobility Restrictions". 
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When receiving the TAU Accept message and there is no ISR indication the UE sets its TIN to "GUTI". When 
ISR is indicated and the UE's TIN indicates "GUTI" the UE's TIN is not changed. When ISR is indicated and the 
Next Update is "P-TMSI" or "RAT-related TMSI" the UE sets its TIN to "RAT-related TMSI". 

In case of an MME change ISR is not activated by the new MME to avoid context transfer procedures with two 
old CN nodes. 

24. If the GUTI was changed the UE acknowledges the new GUTI by returning a Tracking Area Update Complete 
message to the MME. 

NOTE 6: The new MME may initiate RAB establishment after execution of the security functions, or wait until 

completion of the TA update procedure. For the UE, RAB establishment may occur anytime after the TA 
update request is sent. 

In the case of a rejected tracking area update operation, due to regional subscription, roaming restrictions, or access 
restrictions (see TS 23.221 [27] and TS 23.008 [28]) the new MME shall not construct a bearer context. A reject shall 
be returned to the UE with an appropriate cause and the S 1 connection shall be released. Upon return to idle, the UE 
shall act according to TS 23.122 [10]. 

If the new MME is unable to update the bearer context in one or more P-GWs, the new MME shall deactivate the 
corresponding bearer contexts as described in subclause "MME Initiated Dedicated Bearer Deactivation Procedure". 
This shall not cause the MME to reject the tracldng area update. 

The new MME shall determine the Maximum APN restriction based on the received APN Restriction of each bearer 
context from the P-GW and then store the new Maximum APN restriction value. 

If the new MME is unable to support the same number of active bearer contexts as received from old SGSN, the new 
MME should use the prioritisation sent by old SGSN as input when deciding which bearer contexts to maintain active 
and which ones to delete. In any case, the new MME shall first update all contexts in one or more P-GWs and then 
deactivate the context(s) that it cannot maintain as described in subclause "MME Initiated Dedicated Bearer 
Deactivation Procedure". This shall not cause the MME to reject the tracking area update. 

NOTE 7: In case MS (UE) was in PMM-CONNECTED state the bearer contexts are sent already in the Forward 
Relocation Request message as described in subclause "Serving RNS relocation procedures" of 
TS 23.060 [7]. 

If the tracking area update procedure fails a maximum allowable number of times, or if the MME returns a Tracldng 
Area Update Reject (Cause) message, the UE shall enter EMM DEREGISTERED state. 

If the Update Location Ack message indicates a reject, this should be indicated to the UE, and the UE shall not access 
non-PS services until a successful location update is performed. 

5.3.3.3 Routeing Area Update with MME interaction and without SGW change 

The Routeing Area Update without SGW change procedure takes place when a UE that is registered with an MME 
selects a UTRAN or GERAN cell and the SGW is not changed by the procedure. In this case, the UE changes to a 
Routeing Area that the UE has not yet registered with the network. This procedure is initiated by an ECM-IDLE state 
UE and may also be initiated if the UE is in ECM-CONNECTED state. The RA update case is illustrated in Figure 
5.3.3.3-1. 

NOTE 0: This procedure covers the MME to 2G or 3G SGSN RAU and the 2G or 3G SGSN to 2G or 3G SGSN 
RAU with MME interactions, e.g. when ISR is used. 
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Figure 5.3.3.3-1 : Routeing Area Update with IVIIVIE interaction and without SGW change 

NOTE 1: For a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Steps 8 and 10 
concern GTP based S5/S8. 

1 . The UE selects a UTRAN or GERAN cell. This cell is in a Routeing Area that is not yet registered with the 
network or the UE reselects a UTRAN or GERAN cell and is not registered or updated with the SGSN (e.g. 
periodic RAU timer expired while camping on E-UTRAN). The UE in ECM-CONNECTED state may change to 
the GERAN cell through Network Assisted Cell Change (NACC). 

2a. The UE sends a Routeing Area Update Request (old P-TMSI, old RAI, UE Network Capabihty, P-TMSI 
Signature, additional P-TMSI/RAI) message to the new SGSN. 
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If the UE's internal TIN indicates "GUTI" and the UE holds a valid GUTI then the UE indicates the GUTI as the 
old P-TMSI and old RAI. If the UE's TIN indicates "P-TMSI" or "RAT-related TMSI" and the UE holds a valid 
P-TMSI and related RAI then these two elements are indicated as old P-TMSI and old RAI. Mapping a GUTI to 
a P-TMSI and an RAI is specified in Annex H. 

If the UE holds a valid P-TMSI and related RAI then the UE indicates these parameters as additional 
P-TMSI/RAI, regardless whether the old P-TMSI and old RAI indicate the same parameters or parameters 
mapped from a GUTI. 

The old P-TMSI is indicated in the RAU Request message for lu-mode only. For Gb mode the TLLI is derived 
from the value that is determined as the old P-TMSI according to the rules above. The routing parameter that is 
signalled in the RRC signalling to the RNC for routing to the SGSN is derived from the identifier that is 
signalled as the old P-TMSI according to the rules above. For a combined MME/SGSN the RAN is configured to 
route the NRI(s) of this combined node to the same combined node. The RAN is also configured to route NRI(s) 
of P-TMSIs that are generated by the UE's mapping of the GUTIs allocated by the combined node. Such a RAN 
configuration may also be used for separate nodes to avoid changing nodes in the pool caused by inter RAT 
mobility. 

If the UE has a follow-on request, i.e. if there is pending uplink traffic (signalling or data), the 3G SGSN may 
use, as an implementation option, the follow-on request indication to release or keep the lu connection after the 
completion of the RA update procedure. 

Editor's note: It is FES whether, for 0+M purposes, the Release 8 RAU Request should be extended to carry the last 
visited TAI. 

2b. The RNC shall add the Routeing Area Identity before forwarding the message to the SGSN. This RA identity 
corresponds to the RAI in the MM system information sent by the RNC to the UE. The BSS shall add the Cell 
Global Identity (CGI) of the cell where the UE is located before passing the message to the new SGSN. 

Editor's Note: It is FES how the S-TMSI and P-TMSI handling is performed to let RAN select the same CN node for 
GERAN/UTRAN access as for E-UTRAN access, this to support co-location of the MME function and 
the SGSN function in one node. 

35. The new SGSN uses the old RAI received from the UE to derive the old MME address, and sends a Context 
Request (GUTI, New SGSN Address) message to the old MME to get the context for the UE. If the UE is not 
known in the old MME, the old MME responds with an appropriate error cause. If the new SGSN indicates that 
it has authenticated the UE or if the old MME authenticates the UE, the old MME starts a timer. 

3a. If the UE was in ECM-CONNECTED state, the source MME sends a Context Request message to the source 
eNodeB. The source eNodeB begins buffering downlink packets for forwarding rather than transmitting them to 
the UE. 

3b. The source eNodeB sends a Context Response message to the source MME. Data forwarding is optional. 
Editor's Note: It is FES if data forwarding needs to be avoided for this procedure. 

4. The old MME responds with one Context Response (MME Context) message. The MSISDN (if available in the 
old MME), bearer contexts, PDN GW address and Serving GW address are part of the MME Context. The old 
MME maps the EPS bearers to PDP contexts 1-to-l and maps the EPS QoS parameter values of an EPS bearer to 
the pre-Rel-8 QoS parameter values of a bearer context as defined in Annex E. The bearer contexts shall be sent 
in a prioritized order, i.e. the most important bearer context first. The prioritization method is implementation 
dependent, but should be based on the current activity. 

NOTE 2: Assigning the highest priority to the bearer context without TFT could be done to get service continuity 
for all ongoing services regardless of the number of supported EPS bearers in the UE and network. 

The new SGSN shall ignore the UE Network Capability contained in the MME context of the Context Response 
only when it has previously received an UE Network Capability in the Routeing Area Update Request. If UE is 
not known in the old MME, the old MME responds with a appropriate error cause. 

The new SGSN establishes the PDP context(s) in the indicated order. The SGSN deactivates the PDP contexts 
which cannot be established. 

5. Security functions may be executed. Procedures are defined in clause 5.3.10 on "Security Function". 
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6. The SGSN determines whether to relocate the Serving GW or not. The Serving GW is relocated when the old 
Serving GW cannot continue to serve the UE. The SGSN may also decide to relocate the Serving GW in case a 
new Serving GW is expected to serve the UE longer and/or with a more optimal UE to PDN GW path, or in case 
a new Serving GW can be co-located with the PDN GW. Selection of a new Serving GW is performed according 
to clause 4.3.8.2 on "Serving GW selection function". 

The new SGSN sends an Context Acknowledge (Serving GW change indication) message to the old MME. 
Serving GW change indication indicates a new Serving GW has been selected. The old MME marks in its 
context that the information in the GWs and the HSS are invalid. This ensures that the old MME updates the 
GWs and the HSS if the UE initiates a TAU procedure back to the old MME before completing the ongoing 
RAU procedure. 

If the security functions do not authenticate the UE correctly, then the RAU is rejected, and the SGSN sends a 
reject indication to the MME. The MME shall continue as if the Identification and Context Request was never 
received. 

6a. If packets are to be forwarded, the MME sends a Data Forwarding Command message to trigger the eNodeB to 
begin data forwarding. 

6b. Forwarding occurs if applicable. 

Editor's note: It is FES if data forwarding needs to be avoided for this procedure. 

7. In this procedure flow the Serving GW is not relocated. The SGSN sends an Update Bearer Request (new SGSN 
Address and TEID, QoS Negotiated, serving network identity, RAT type, ISR) message to the Serving GW. The 
information element ISR indicates whether ISR is established. 

When the Update Bearer Request does not indicate ISR the S-GW deletes any ISR resources by sending a Delete 
Bearer Request to the other CN node that has bearer resources on the S-GW reserved. 

8. The Serving GW informs the PDN GW(s) about the change of for example the RAT type that e.g. can be used 
for charging, by sending the message Update Bearer Request (Serving GW Address and TEID, RAT type) to the 
PDN GW(s) concerned. 

9. If dynamic PCC is deployed, and RAT type information needs to be conveyed from the PDN GW to the PCRF, 
then the PDN GW shall send RAT type information to the PCRF by means of an IP-CAN Session Modification 
procedure as defined in TS 23.203 [6]. 

NOTE 3: The PDN GW does not need to wait for the PCRF response, but continues in the next step. If the PCRF 
response leads to an EPS bearer modification the PDN GW should initiate a bearer update procedure. 

10. The PDN GW updates its context field and returns an Update Bearer Response (MSISDN, PDN GW address and 
TEID) message to the Serving GW. MSISDN is included if the PDN GW has it stored in its UE context. 

1 1. The Serving GW updates its context fields and returns an Update Bearer Response (Serving GW address and 
TEID, PDN GW address and TEIDs (for GTP-based S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN 
GW(s) for uplink traffic) message. 

12. The new SGSN verifies whether it holds subscription data for the UE identified by the P-TMSI, the additional 
PTMSI/RAI or by the IMSI received with the context data from the old CN node. If there are no subscription 
data in the new SGSN for this UE then the new SGSN informs the HSS of the change of the SGSN by sending 
an Update Location (SGSN Number, SGSN Address, IMSI) message to the HSS. 

13. The HSS sends a Cancel Location (IMSI, Cancellation Type) message to the old SGSN with the Cancellation 
Type set to Update Procedure. 

When receiving the Cancel Location message and the old node is an SGSN and the timer started in step 3 is not 
running, the old SGSN removes the MM and bearer contexts. Otherwise, the contexts are removed when the 
timer expires. It also ensures that the MM context is kept in the old SGAN for the case the UE initiates another 
TAU procedure before completing the ongoing RAU procedure to the new SGSN. The old SGSN acknowledges 
with a Cancel Location Ack (IMSI) message. 

NOTE 4: ISR is never indicated from new to old SGSN. 
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An old SGSN deletes all bearer resources of an UE in any case when the timer started in step 3 expires, which is 
independent from receiving a Cancel Location message. 

When the timer started in step 3 expires and the old node is an MME the MME releases any EPS bearer 
resources of the UE. 

If the old MME has an SI -MME association for the UE, the source MME sends a Sl-U Release Command to the 
source eNodeB. It is FES what triggers the sending of this message. The RRC connection is released by the 
source eNodeB. The source eNodeB confirms the release of the RRC connection and of the Sl-U connection by 
sending a Sl-U Release Complete message to the source MME. 

14 The HSS sends Insert Subscriber Data (IMSI, Subscription Data) to the new SGSN. The new SGSN vaUdates the 
UE's presence in the (new) RA. If due to regional subscription restrictions or access restrictions the UE is not 
allowed to be attached in the RA, the SGSN rejects the Routeing Area Update Request with an appropriate cause 
to the UE, and may return an Insert Subscriber Data Ack (IMSI, SGSN Area Restricted) message to the HSS. If 
all checks are successful, the SGSN constructs an MM context for the UE and returns an Insert Subscriber Data 
Ack (IMSI) message to the HSS. 

15. The HSS acknowledges the Update Location message by sending an Update Location Ack to the new SGSN. If 
the Update Location is rejected by the HSS, the new SGSN rejects the Attach Request from the UE with an 
appropriate cause. 

18. The new SGSN responds to the UE with a Routeing Area Update Accept (P-TMSI, P-TMSI signature, ISR) 
message to the UE. P-TMSI is included if the SGSN allocates a new P-TMSI. 

ISR indicates to the UE that its GUTI and list of TAs remain registered with the network and remain valid in the 
UE. If ISR is not indicated the UE sets in its internal data the update status of the GUTI to "update-needed". 

When receiving the RAU Accept message and there is no ISR indication the UE sets its TIN to "P-TMSI". When 
ISR is indicated and the UE's TIN indicates "P-TMSI" the TIN is not changed. When ISR is indicated and the 
UE's TIN indicates "GUTI" or "RAT-related TMSI" the UE sets its TIN to "RAT-related TMSI". 

In case of an SGSN change ISR is not activated by the new SGSN to avoid context transfer procedures with two 
old CN nodes. 



19. If P-TMSI was included in the Routeing Area Update Accept message, the UE acknowledges the new P-TMSI 
by returning a Routeing Area Update Complete message to the SGSN. 

20. For lu-mode, if the UE has uplink data or signalling pending it shall send a Service Request (P-TMSI, CKSN, 
Service Type) message to the new SGSN. If a P-TMSI was allocated in step 18, that P-TMSI is the one included 
in this message. Service Type specifies the requested service. Service Type shall indicate one of the following: 
Data or Signalling. 

21. If the UE has sent the Service Request, the new 3G SGSN requests the RNC to establish a radio access bearer by 
sending a RAB Assignment Request (RAB ID(s), QoS Profile(s), GTP SNDs, GTP SNUs, PDCP SNUs) 
message to the RNC. If Direct Tunnel is established the SGSN provides to the RNC the Serving GW's Address 
for User Plane and TEID for uplink data. 

22. If the SGSN established Direct Tunnel in step 21) it shall send Update Bearer Request to the Serving GW and 
include the RNC's Address for User Plane and downlink TEID for data. The Serving GW updates the Address 
for User Plane and TEID for downlink data and return an UpdateBearer Response. 

NOTE 5: EPS does not support any CAMEL procedures. 

NOTE 6: The new SGSN may initiate RAB establishment after execution of the security functions (step 5), or wait 
until completion of the RA update procedure. For the MS, RAB establishment may occur anytime after 
the RA update request is sent (step 2). 

In the case of a rejected routeing area update operation, due to regional subscription, roaming restrictions, or access 
restrictions (see TS 23.221 [27] and TS 23.008 [28]) the new SGSN shall not construct an MM context. A reject shall 
be returned to the UE with an appropriate cause. The UE shall not re-attempt a routeing area update to that RA. The 
RAI value shall be deleted when the UE is powered up. It is FES whether the RAI value being deleted until power up as 
specified both here and in TS 23.060 [7] is correct. 
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If the network supports the MOCN configuration for network sharing, the SGSN may, if the UE is not a 'Network 
Sharing Supporting MS', in this case decide to initiate redirection by sending a Reroute Command to the RNS, as 
described in TS 23.251 [24] instead of rejecting the routeing area update. 

If the new SGSN is unable to update the bearer context in one or more P-GWs, the new SGSN shall deactivate the 
corresponding bearer contexts as described in clause "SGSN-initiated PDP Context Deactivation Procedure" of 
TS 23.060 [7]. This shall not cause the SGSN to reject the routeing area update. 

The bearer contexts shall be sent from old to new SGSN in a prioritized order, i.e. the most important bearer context 
first in the SGSN Context Response message. (The prioritization method is implementation dependent, but should be 
based on the current activity). 

The new SGSN shall determine the Maximum APN restriction based on the received APN Restriction of each bearer 
context from the P-GW and then store the new Maximum APN restriction value. 

If the new SGSN is unable to support the same number of active bearer contexts as received from the old MME/SGSN, 
the new SGSN should use the prioritisation sent by old MME/SGSN as input when deciding which bearer contexts to 
maintain active and which ones to delete. In any case, the new SGSN shall first update all contexts in one or more P- 
GWs and then deactivate the context(s) that it cannot maintain as described in subclause "SGSN-initiated PDP Context 
Deactivation Procedure" of TS 23.060 [7]. This shall not cause the SGSN to reject the routeing area update. 

NOTE 6: In case the UE was in PMM-CONNECTED state the bearer contexts are sent already in the Forward 
Relocation Request message as described in subclause "Serving RNS relocation procedures" of 
TS 23.060 [7]. 

If the routeing area update procedure fails a maximum allowable number of times, or if the SGSN returns a Routeing 
Area Update Reject (Cause) message, the UE shall enter PMM DETACHED state. 

If the Update Location Ack message indicates a reject, this should be indicated to the UE, and the UE shall not access 
non-PS services until a successful location update is performed. 

5.3.3.6 Routeing Area Update with MME interaction and with SGW change 

The Routeing Area Update with SGW change procedure takes place when a UE that is registered with an MME selects 
a UTRAN or GERAN cell and the SGW is changed by the procedure. In this case, the UE changes to a Routeing Area 
that the UE has not yet registered with the network. This procedure is initiated by an ECM-IDLE state UE and may also 
be initiated if the UE is in ECM-CONNECTED state. This RA update case is illustrated in Figure 5.3.3.6-1. 

NOTE 0: This procedure covers the MME to 2G or 3G SGSN RAU and the 2G or 3G SGSN to 2G or 3G SGSN 
RAU with MME interactions, e.g when ISR is used. 
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Figure 5.3.3.6-1 : Routeing Area Update with IVIIVIE interaction and with SGW change 

NOTE 1: For a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Steps 8 and 10 
concern GTP based S5/S8 
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1. The UE selects a UTRAN or GERAN cell. This cell is in a Routeing Area that is not yet registered with the 
network. The UE in ECM-CONNECTED state may change to the GERAN cell through Network Assisted Cell 
Change (NACC). 

2a. The UE sends a Routeing Area Update Request (old RAI, old P-TMSI, UE Network Capability, P-TMSI 
Signature, additional P-TMSI/RAI) message to the new SGSN. 

If the UE's TIN indicates "GUTI" and the UE holds a valid GUTI then the UE indicates the GUTI as the old 
P-TMSI and old RAI. If the UE's TIN indicates "P-TMSI" or "RAT-related TMSI" and the UE holds a vaHd 
P-TMSI and related RAI then these two elements are indicated as old P-TMSI and old RAI. Mapping a GUTI to 
a P-TMSI and an RAI is specified in Annex H. 

If the UE holds a valid P-TMSI and related RAI then the UE indicates these parameters as additional 
P-TMSI/RAI, regardless whether the old P-TMSI and old RAI indicate the same parameters or parameters 
mapped from a GUTI. 

The old P-TMSI is indicated in the RAU Request message for lu-mode only. For Gb mode the TLLI is derived 
from the value that is determined as the old P-TMSI according to the rules above. The routing parameter that is 
signalled in the RRC signalling to the RNC for routing to the SGSN is derived from the identifier that is 
signalled as the old P-TMSI according to the rules above. For a combined MME/SGSN the RAN is configured to 
route the NRI(s) of this combined node to the same combined node. The RAN is also configured to route NRI(s) 
of P-TMSIs that are generated by the UE's mapping of the GUTIs allocated by the combined node. Such a RAN 
configuration may also be used for separate nodes to avoid changing nodes in the pool caused by inter RAT 
mobility. 

If the UE has a follow-on request, i.e. if there is pending uplink traffic (signalling or data), the 3G-SGSN may 
use, as an implementation option, the follow-on request indication to release or keep the lu connection after the 
completion of the RA update procedure. 

Editor's note: It is FES whether, for 0+M purposes, the Release 8 RAU Request should be extended to carry the last 
visited TAI. 

Editor's Note: It is FES how the S-TMSI and P-TMSI handling is performed to let RAN select the same CN node for 
GERAN/UTRAN access as for E-UTRAN access, this to support co-location of the MME function and 
the SGSN function in one node. 

2b. The RNC shall add the Routeing Area Identity before forwarding the message to the SGSN. This RA identity 
corresponds to the RAI in the MM system information sent by the RNC to the UE. The BSS shall add the Cell 
Global Identity (CGI) of the cell where the UE is located before passing the message to the new SGSN. 

Editor's note: It is FES how the S-TMSI and P-TMSI handling is performed to let RAN select the same CN node for 
GERAN/UTRAN access as for E-UTRAN access, this to support co-location of the MME function and 
the SGSN function in one node. 

3. The new SGSN uses the old TAI received from the UE to derive the old MME/SGSN address, and sends a 

Context Request (old GUTI, New SGSN Address) message to the old MME/SGSN to get the context for the UE. 
If the UE is not known in the old MME/SGSN, the old MME/SGSN responds with an appropriate error cause. If 
the new SGSN indicates that it has authenticated the UE or if the old MME/SGSN authenticates the UE, the old 
MME/SGSN starts a timer. 

3b. If the UE was in ECM-CONNECTED state, the source MME sends a Context Request message to the source 
eNodeB. The source eNodeB begins buffering downlink packets for forwarding rather than transmitting them to 
the UE. 

If the UE was in PMM-CONNECTED state, the source SGSN sends a Context Request message to the source 
RNS. The source RNC begins buffering downlink packets for forwarding rather than transmitting them to the 
UE. 

3c. The source eNodeB sends a Context Response message to the source MME. Data forwarding is optional. 

The source RNC sends a Context Response message to the source SGSN. Data forwarding is optional. 
Editor's note: It is FES if data forwarding needs to be avoided for this procedure. 
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4. The old MME/SGSN responds with one Context Response (MME Context) message. The MSISDN (if available 
in the old MME), bearer contexts, PDN GW Address and Serving GW Address are part of the MME context. 
The old MME/SGSN maps the EPS bearers to PDF contexts 1-to-l and maps the EPS QoS parameter values of 
an EPS bearer to the pre-Rel-8 QoS parameter values of a PDP context as defined in Annex E. The bearer 
contexts shall be sent in a prioritized order, i.e. the most important bearer context first. The prioritization method 
is implementation dependent, but should be based on the current activity. 

NOTE 2: Assigning the highest priority to the bearer context without TFT could be done to get service continuity 
for all ongoing services regardless of the number of supported EPS bearers in the UE and network. 

The new SGSN shall ignore the UE Network Capability contained in MME Context of the Context Response 
only when it has previously received an UE Network Capability in the Routeing Area Request. If UE is not 
known in the old MME, the old MME responds with a appropriate error cause. 

The new SGSN establishes the PDP context(s) in the indicated order. The SGSN deactivates the PDP contexts 
which cannot be established. 

5. Security functions may be executed. Procedures are defined in clause 5.3.10 on "Security Function". 

6. The SGSN determines whether to relocate the Serving GW or not. The Serving GW is relocated when the old 
Serving GW cannot continue to serve the UE. The SGSN may also decide to relocate the Serving GW in case a 
new Serving GW is expected to serve the UE longer and/or with a more optimal UE to PDN GW path, or in case 
a new Serving GW can be co-located with the PDN GW. Selection of a new Serving GW is performed according 
to clause 4.3.8.2 on "Serving GW selection function". 

The new SGSN sends a Context Acknowledge (Serving GW change indication) message to the old MME/SGSN. 
Serving GW change indication indicates a new Serving GW has been selected. The old MME/SGSN marks in its 
context that the information in the GWs and the HSS are invalid. This ensures that the old MME updates the 
GWs and the HSS if the UE initiates a RAU procedure back to the old MME before completing the ongoing 
RAU procedure. 

If the security functions do not authenticate the UE correctly, then the RAU is rejected, and the SGSN sends a 
reject indication to the MME. The MME shall continue as if the Identification and Context Request was never 
received. 

If packets are to be forwarded, the MME sends a Data Forwarding Command message to trigger the eNodeB to 
begin data forwarding. Forwarding occurs if applicable. 

Editor's note: It is FES if data forwarding needs to be avoided for this procedure. 

7. In this procedure flow the Serving GW is relocated. The SGSN sends a Create Bearer Request (IMSI, bearer 
contexts, SGSN Context ID, RAT Type, Type, the Protocol Type over S5/S8, etc) message to the selected new 
Serving GW. The PDN GW address is indicated in the bearer contexts. Type indicates to the Serving GW to 
send the Update Bearer Request the PDN GW. The Protocol Type over S5/S8 is provided to Serving GW which 
protocol should be used over S5/S8 interface. 

8. The new Serving GW sends the message Update Bearer Request (Serving GW Address, Serving GW TEID, 
RAT type) to the PDN GW concerned. 

9. If dynamic PCC is deployed, and RAT type information needs to be conveyed from the PDN GW to the PCRF, 
then the PDN GW shall send RAT type information to the PCRF by means of an IP-CAN Session Modification 
procedure as defined in TS 23.203 [6]. 

NOTE 3: The PDN GW does not need to wait for the PCRF response, but continues in the next step. If the PCRF 
response leads to an EPS bearer modification the PDN GW should initiate a bearer update procedure. 

10. The PDN GW updates its context field and returns an Update Bearer Response (PDN GW address and TEID, 
MSISDN) message to the Serving GW. The MSISDN is included if the PDN GW has it stored in its UE context. 

1 1. The new Serving GW updates its bearer context. This allows the Serving GW to route Bearer PDUs to the PDN 
GW when received from RNC. The new Serving GW returns an Create Bearer Response (Serving GW address 
and TEID, PDN GW Address and TEIDs (for GTP-based S5/S8) or GRE keys (for PMIP-based S5/S8) at the 
PDN GW(s) for uplink traffic) message to the SGSN. 
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12. The new SGSN verifies whether it holds subscription data for the UE identified by the P-TMSI, the additional 
P-TMSI/RAI or by the IMSI received with the context data from the old CN node. If there are no subscription 
data in the new SGSN for this UE then the new SGSN informs the HSS of the change of SGSN by sending an 
Update Location (SGSN Number, SGSN Address, IMSI) message to the HSS. 

13. The HSS sends a Cancel Location (IMSI, Cancellation Type) message to the old SGSN with the Cancellation 
Type set to Update Procedure. 

When the timer started in step 3 expires and the old node is an SGSN, the old SGSN removes the MM and bearer 
contexts. Otherwise, the contexts are removed when the timer expires. It also ensures that the MM context is 
kept in the old SGSN for the case the UE initiates another TAU procedure before completing the ongoing RAU 
procedure to the new SGSN. The old SGSN acknowledges with a Cancel Location Ack (IMSI) message. 

NOTE 6: ISR is never indicated from new to old SGSN. 

An old SGSN deletes all bearer resources of an UE in any case when the timer started in step 3 expires, which is 
independent from receiving a Cancel Location message. 

If the timer started in step 3 expires and the old node is an MME the MME releases any EPS bearer resources of 
the UE. 

If the old MME has an SI -MME association for the UE, the source MME sends a Sl-U Release Command to the 
source eNodeB. It is FES what triggers the sending of this message. The RRC connection is released by the 
source eNodeB. The source eNodeB confirms the release of the RRC connection and of the Sl-U connection by 
sending a Sl-U Release Complete message to the source MME. 

14 The HSS sends Insert Subscriber Data (IMSI, Subscription Data) to the new SGSN. The new SGSN vahdates the 
UE's presence in the (new) RA. If due to regional subscription restrictions or access restrictions the UE is not 
allowed to be attached in the RA, the SGSN rejects the Routeing Area Update Request with an appropriate cause 
to the UE, and may return an Insert Subscriber Data Ack (IMSI, SGSN Area Restricted) message to the HSS. If 
all checks are successful, the SGSN constructs an MM context for the UE and returns an Insert Subscriber Data 
Ack (IMSI) message to the HSS. 

15. The HSS acknowledges the Update Location message by sending an Update Location Ack to the new SGSN. If 
the Update Location is rejected by the HSS, the new SGSN rejects the Attach Request from the UE with an 
appropriate cause. 

16. When the timer started in step 3 expires and the old MME/SGSN received the Serving GW change indication in 
the Context Acknowledge message, the old MME/SGSN deletes the EPS bearer resources by sending Delete 
Bearer Request (Cause, TEID) messages to the old Serving GW. Cause indicates to the old Serving GW that the 
old Serving GW shall not initiate a delete procedure towards the PDN GW. If the Serving GW has not changed, 
the old MME/SGSN does not delete the bearers. If ISR is established on the S-GW then the S-GW deletes the 
bearer resources on the other old CN node by sending Delete Bearer Request message(s) to that CN node. 

17. The old Serving GW acknowledges with Delete Bearer Response (TEID) messages. 

18. The new SGSN responds to the UE with a Routeing Area Update Accept (P-TMSI, P-TMSI Signature) message. 

If ISR is not indicated the UE sets in its internal data the update status of the GUTI to "update-needed". 

In case of an S-GW change ISR is never indicated by the SGSN to the UE as it needs a TAU with the same 
S-GW first to activate ISR. In case of an SGSN change ISR is not activated by the new SGSN to avoid context 
transfer procedures with two old CN nodes. 

When receiving the RAU Accept message and there is no ISR indication the UE sets its TIN to "P-TMSI". When 
ISR is indicated and the UE's TIN indicates "P-TMSI" the TIN is not changed. When ISR is indicated and the 
UE's TIN indicates "GUTI" or "RAT-related TMSI" the UE sets its TIN to "RAT-related TMSI". 

19. If the P-TMSI was included in the RAU Accept message.the UE acknowledges the new P-TMSI by returning a 
Routeing Area Update Complete message to the SGSN. 

20. For lu-mode, if the UE has uplink data or signalling pending it shall send a Service Request (P-TMSI, CKSN, 
Service Type) message to the new SGSN. If a P-TMSI was allocated in step 18, that P-TMSI is the one included 
in this message. Service Type specifies the requested service. Service Type shall indicate one of the following: 
Data or Signalling. 



ETSI 



3GPP TS 23.401 version 8.2.0 Release 8 



71 



ETSI TS 123 401 V8.2.0 (2008-10) 



21. If the UE has sent the Service Request, the new 3G SGSN requests the RNC to estabUsh a radio access bearer by 
sending a RAB Assignment Request (RAB ID(s), QoS Profile(s), GTP SNDs, OTP SNUs, PDCP SNUs) 
message to the RNC. If Direct Tunnel is estabUshed the SGSN provides to the RNC the Serving GW's Address 
for User Plane and TEID for uplink data. 

22. If the SGSN established Direct Tunnel in step 21) it shall send Update Bearer Request to the Serving GW and 
include the RNCs Address for User Plane and downlink TEID for data. The Serving GW updates the Address 
for User Plane and TEID for downlink data and return an Update Bearer Response. 

NOTE 7: EPS does not support any CAMEL procedures. 

In the case of a rejected routeing area update operation, due to regional subscription, roaming restrictions, access 
restrictions (see TS 23.221 [80] and TS 23.008 [79]) or because the SGSN cannot determine the HLR address to 
establish the locating updating dialogue, the new SGSN shall not construct an MM context. A reject shall be returned to 
the UE with an appropriate cause. The UE does not re-attempt a routeing area update to that RA. The RAI value shall 
be deleted when the UE is powered-up. It is FES whether the RAI value being deleted until power up as specified both 
here and in TS 23.060 [7] is correct. 

If the new SGSN is unable to update the bearer context in one or more P-GWs, the new SGSN shall deactivate the 
corresponding bearer contexts as described in clause "SGSN-initiated PDP Context Deactivation Procedure" of 
TS 23.060 [7]. This shall not cause the SGSN to reject the routeing area update. 

The bearer contexts shall be sent from old MME to new SGSN in a prioritized order, i.e. the most important bearer 
context first in the Context Response message. (The prioritization method is implementation dependent, but should be 
based on the current activity). 

The new SGSN shall determine the Maximum APN restriction based on the received APN Restriction of each bearer 
context from the P-GW and then store the new Maximum APN restriction value. 

If the new SGSN is unable to support the same number of active bearer contexts as received from old MME, the new 
SGSN should use the prioritisation sent by old MME as input when deciding which contexts to maintain active and 
which ones to delete. In any case, the new SGSN shall first update all contexts in one or more P-GWs and then 
deactivate the context(s) that it cannot maintain as described in subclause "SGSN-initiated PDP Context Deactivation 
Procedure" of TS 23.060 [7]. This shall not cause the SGSN to reject the routeing area update. 

If the routeing area update procedure fails a maximum allowable number of times, or if the SGSN returns a Routeing 
Area Update Reject (Cause) message, the MS shall enter IDLE state. 
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5.3.4 Service Request procedures 
5.3.4.1 UE triggered Service Request 
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Figure 5.3.4.1-1: UE triggered Service Request procedure 

NOTE: For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402 [2]. Steps 9 and 1 1 concern GTP- 
based S5/S8. 

1. The UE sends NAS message Service Request (S-TMSI) towards the MME encapsulated in an RRC message to 
the eNodeB. The RRC message(s) that can be used to carry this NAS message are described in TS 36.300 [5]. 

2. The eNodeB forwards NAS message to MME. NAS message is encapsulated in an Sl-AP: Initial UE Message 
(NAS message, Cell Global ID of the serving cell). Details of this step are described in TS 36.300 [5]. 

3. NAS authentication procedures may be performed. 

4. The MME sends Sl-AP Initial Context Setup Request (Serving GW address, Sl-TEID(s) (UL), Bearer QoS(s), 
Security Context, MME Signalling Connection Id, Handover Restriction List) message to the eNodeB. This step 
activates the radio and SI bearers for all the active EPS Bearers. The eNodeB stores the Security Context, MME 
Signalling Connection Id, Bearer QoS profile(s) and Sl-TEID(s) in the UE RAN context. The step is described 
in detail in TS 36.300 [5]. Handover Restriction List is described in clause 4.3.5.7 "Mobility Restrictions". 

5. The eNodeB performs the radio bearer establishment procedure. The user plane security is established at this 
step, which implicitly confirms the Service Request. This step is described in detail in TS 36.300 [5]. When user 
plane security has been established the EPS bearer state is synchronized between the UE and the network, i.e. the 
UE should remove the EPS bearer for which no radio bearers are setup. 

6. The uplink data from the UE can now be forwarded by eNodeB to the Serving GW. The eNodeB sends the 
uplink data to the Serving GW address and TEID provided in the step 4. 

7. The eNodeB sends an Sl-AP message Initial Context Setup Complete (eNodeB address, List of accepted EPS 
bearers. List of rejected EPS bearers, SI TEID(s) (DL)) to the MME. This step is described in detail in 

TS 36.300 [5]. 



ETSI 



3GPP TS 23.401 version 8.2.0 Release 8 



73 



ETSI TS 123 401 V8.2.0 (2008-10) 



8. The MME sends an Update Bearer Request message (eNodeB address, SI TEID(s) (DL) for the accepted EPS 
bearers, Delay DownUnk Packet Notification Request, RAT Type) to the Serving GW. The Serving GW is now 
able to transmit downlink data towards the UE. The usage of the Delay Downlink Packet Notification Request 
Information Element is specified in clause 5.3.4.2 below. 

If any EPS bearers are to be released the MME triggers the bearer release procedure as specified in 
clause 5.4.4.2. 

9. If the RAT Type has changed compared to the last reported RAT Type, the Serving GW shall send the Update 
Bearer Request message (RAT Type) to the PDN GW. 

10. If dynamic PCC is deployed, the PDN GW interacts with the PCRF to get the PCC rule(s) according to the RAT 
Type by means of a PCEF initiated IP-CAN Session Modification procedure as defined in TS 23.203 [6]. If 
dynamic PCC is not deployed, the PDN GW may apply local QoS policy. 

1 1. The PDN GW sends the Update Bearer Response to the Serving GW. 

12. The Serving GW sends an Update Bearer Response to the MME. 

5.3.4.2 Handling of abnormal conditions in UE triggered Service Request 

Editor's note: If /when suitable CT4 specifications are available, many of the details included below can be moved 
into it. However, as the details impact the interoperation between MME and S-GW they are currently 
included in this TS 23.401 (needed to ensure that the procedure is "stable"; avoids RAN impacts and that 
the negative impacts of shortening the DRX interval on UE battery life are avoided). 

Under certain conditions, the current UE triggered Service Request procedure can cause unnecessary Downlink Packet 
Notification messages which increase the load of the MME. 

This can occur when uplink data sent in step 6 causes a response on the downlink which arrives at the Serving GW 
before the Update Bearer Request message, step 8. This data cannot be forwarded from the Serving GW to the eNodeB 
and hence it triggers a Downlink Data Notification message. 

If the MME receives a Downlink Data Notification after step 2 and before step 9, the MME shall not send SI interface 
paging messages. However, across all the UEs on that MME, the MME shall monitor the rate at which these events 
occur. If the rate becomes significant (as configured by the operator) and the MME's load exceeds an operator 
configured value, the MME shall indicate "Delay Downlink Packet Notification Request" with parameter D to the 
Serving Gateway, where D is the requested delay given as an integer multiple of [50 ms (FES)], or zero. The Serving 
GW then uses this delay in between receiving downlink data and sending the Downlink Data Notification message. 

Editor's note: The determination of the "rate that is significant" is FES. 

NOTE 1 : A low rate of reception of Downlink Data Notifications between steps 2 and 9 should be considered a 

normal circumstance, e.g. due to the chance that a UE Terminating call/session is initiated at roughly the 
same time as the UE triggered Service Request procedure. 

NOTE 2: It is recommended that this rate is determined over [60 (FES)] second periods. 

The MME shall use the step 8, Update Bearer Request of the UE initiated Service Request procedure to indicate "Delay 
Downlink Packet Notification Request" to the Serving GW. 

To determine the amount of delay requested by a given MME, the Serving GW either uses the last Update Bearer 
Request message which is part of a Service Request procedure, or, just uses one of the Service Request procedure's 
Update Bearer Request messages received within the preceding [30 (FES)] seconds. The latter mode of operation shall 
be taken into account when implementing the MME. 

The MME is responsible for setting the value of D. The exact algorithm for setting the value is implementation 
dependent, two examples are given below to serve as a guideline: 

EXAMPLE 1 : The MME adaptively increases the value of D when the rate of unnecessary Downlink Data 

Notifications is too high; and correspondingly it decreases the value when the rate is not too high. 
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EXAMPLE 2: When unnecessary Downlink Data Notifications arrive, the MME measures the average time from 
the reception of the unnecessary Downhnk Data Notification to the reception of the Update Bearer 
Response from the Serving GW in the same UE triggered Service Request Procedure. The value of 
D is calculated from this average, by adding a safety margin. 

Normally, upon receipt of a downlink data packet for which there is no DL-TEID of the SI user plane tunnel, the S-GW 
shall send the Downlink Data Notification message to the MME without delay. 

If the S-GW determines from the last Update Bearer Request message which is part of a Service Request procedure that 
a given MME request delaying of the Downlink Packet Notification by a delay of D, it shall (only for UEs of that 
MME) buffer the Downlink Data for a period D. If the DL-TEID and eNodeB address for the UE is received before the 
expiry of the timer, the timer shall be cancelled and the Network triggered Service Request procedure is finished 
without sending the Downlink Data Notification message to the MME, i.e. DL data are sent to the UE. Otherwise the 
Downlink Data Notification message is sent to the MME when the timer expires. 



5.3.4.3 
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Figure 5.3.4.3-1 : Network triggered Service Request procedure 



If the MME needs to signal with the UE that is in ECM-IDLE state, e.g. to perform the MME/HSS -initiated detach 
procedure for the ECM-IDLE mode UE or receive control signalling (e.g. Create Dedicated Bearer Request or Modify 
Dedicated Bearer Request), the MME starts network triggered service request procedure from step 3. 

If ISR is activated, when the Serving GW receives a Create Dedicated Bearer Request or Modify Bearer Request for a 
UE, and the SGW does not have a downlink Sl-U and the SGSN has notified the Serving GW that the UE has moved to 
PMM-IDLE or STANDBY state, the Serving GW buffers signalling messages and triggers MME and SGSN to page 
UE. In this case the S-GW will be notified about the current RAT type based on the UE triggered service request 
procedure. The S-GW will go on executing the dedicated bearer activation or dedicated bearer modification procedure, 
i.e. send the corresponding buffered signalling to MME or SGSN which UE resides in now and inform the current RAT 
type to the PDN GW if the RAT type has been changed compared to the last reported RAT Type. If dynamic PCC is 
deployed, the current RAT type information shall also be conveyed from the PDN GW to the PCRF. If the PCRF 
response leads to an EPS bearer modification the PDN GW should initiate a bearer update procedure as specified in 
clause 5.4.2.1 below.. 

1. When the Serving GW receives a downlink data packet for a UE known as not user plane connected (i.e. the 
S-GW context data indicates no downlink user plane TEID), it buffers the downlink data packet, and identifies 
which MME or SGSN is serving that UE. 

If that MME has requested the S-GW to delay sending the Downlink Data Notification (see clause 5.3.4.2 on 
"Handling of abnormal conditions in UE triggered Service Request"), the Serving GW buffers the downlink data 
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and waits until the timer expires before continuing with step 2. If the DL-TEID and eNodeB address for that UE 
is received before the expiry of the timer, the timer shall be cancelled and the Network triggered Service Request 
procedure is finished without executing the steps below, i.e. DL data are sent to the UE. 

If the Serving GW receives additional downlink data packets for this UE before the expiry of the timer, the 
Serving GW does not restart this timer. 

2. The Serving GW sends a Downlink Data Notification message to the MME and SGSN nodes for which it has 
control plane connectivity for the given UE. The MME and SGSN respond to the S-GW with a Downlink Data 
Notification Ack message. 

If the Serving GW receives additional downlink data packets for this UE, the Serving GW buffers these 
downlink data packets and the Serving GW does not send a new Downlink Data Notification. 

3a. If the UE is registered in the MME, the MME sends a Paging message (NAS Paging ID, TAI(s), Paging DRX 
ID) to each eNodeB belonging to the tracking area(s) in which the UE is registered. The step is described in 
detail in TS 36.300 [5]. Steps 3-4 are omitted if the MME already has a signalling connection over SI -MME 
towards the UE. 

3b. If the UE is registered in the SGSN, the SGSN sends paging messages to RNC/BSS, which is described in 
detail in TS 23.060 [7]. 

4a. If eNodeB s receive paging messages from the MME, the UE is paged by the eNodeB s. The step is described in 
detail in TS 36.300 [5]. 

4b. If RNC/BSS nodes receive paging messages from the SGSN the UE is paged by the RNSC/BSS, which is 
described in detail in TS 23.060 [7] 

5. Upon reception of paging indication in E-UTRAN access, the UE initiates the UE triggered Service Request 
procedure, which is specified in clause 5.3.4.1. 

Upon reception of paging indication in UTRAN or GERAN access, the MS shall respond in respective access as 
specified TS 24.008 [47] and the SGSN shall notify the S-GW. 

The MME and/or SGSN supervises the paging procedure with a timer. If the MME and/or SGSN receives no 
response from the UE to the Paging Request message, it may repeat the paging. The repetition strategy is 
operator dependent. 

If the MME and/or SGSN receives no response from the UE after this paging repetition procedure, it shall use 
the Update Bearer Request [FES] message to notify the Serving GW about the paging failure. In that case, if ISR 
is not active, the Serving GW deletes the buffered packet(s). If ISR is active and the Serving GW receives paging 
failure from both SGSN and MME, the Serving GW deletes the bufferd packet(s). 

6a. If ISR is active and paging response is received in E-UTRAN access the Serving GW sends a "Stop Paging" 
message to the SGSN. 

6b. If ISR is active and paging response is received in UTRAN or GERAN access the Serving GW sends a "Stop 
Paging" message to the MME. 

The Serving GW transmits downlink data towards the UE only via the RAT where paging response was received. 

5.3.5 S1 release procedure 

This procedure is used to release the logical Sl-AP signalling connection (over SI -MME) and all SI bearers (in Sl-U) 
for a UE. The procedure will move the UE from ECM-CONNECTED to ECM-IDLE in both the UE and MME, and all 
UE related context information is deleted in the eNodeB. 

The initiation of S 1 Release procedure is either: 

- eNodeB -initiated with cause e.g. O&M Intervention, Unspecified Failure, User Inactivity, Repeated RRC 
signalling Integrity Check Failure, Release due to UE generated signalling connection release, etc.; or 

- MME-initiated with cause e.g. authentication failure, detach, etc. 

Both eNodeB -initiated and MME-initiated SI release procedures are shown in Figure 5.3.5-1. 
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Figure 5.3.5-1 : SI Release Procedure 

1. If the eNodeB detects a need to release the UE's signalHng connection and all radio bearers for the UE, the 
eNodeB sends an SI UE Context Release Request (Cause) message to the MME. Cause indicates the reason for 
the release (e.g. O&M intervention, unspecified failure, user inactivity, repeated integrity checking failure, or 
release due to UE generated signalling connection release). 

NOTE: Step 1 is only performed when the eNodeB -initiated SI release procedure is considered. Step 1 is not 
performed and the procedure starts with Step 2 when the MME-initiated S 1 release procedure is 
considered. 



2. The MME sends an Update Bearer Request message to the S-GW that requests the release of all Sl-U bearers for 
the UE. This message is triggered either by an SI Release Request message from the eNodeB, or by another 
MME event. 

3. The S-GW releases all eNodeB related information (address and TEIDs) for the UE and responds with an Update 
Bearer Response message to the MME. Other elements of the UE's S-GW context are not affected. The S-GW 
retains the Sl-U configuration that the S-GW allocated for the UE's bearers. The S-GW starts buffering 
downlink packets received for the UE and initiating the "Network Triggered Service Request" procedure, 
described in sub-clause 5.3.4.3, if downlink packets arrive for the UE. 

4. The MME releases SI by sending the SI UE Context Release Command (Cause) message to the eNodeB. 

5. If the RRC connection is not already released, the eNodeB sends a RRC Connection Release message to the UE 
in Acknowledged Mode. Once the message is acknowledged by the UE, the eNodeB deletes the UE's context. 

6. The eNodeB confirms the SI Release by returning an SI UE Context Release Complete message to the MME. 
With this, the signalling connection between the MME and the eNodeB for that UE is released. This step shall be 
performed promptly after step 4, e.g. it shall not be delayed in situations where the UE does not acknowledge the 
RRC Connection Release. 

The MME deletes any eNodeB related information (address and TEIDs) from the UE's MME context, but, 
retains the rest of the UE's MME context including the S-GW's Sl-U configuration information (address and 
TEIDs). All EPS bearers established for the UE are preserved in the MME and in the Serving GW. 

If the cause of SI release is different from User inactivity, e.g. loss of RRC connection, the MME shall trigger 
the MME Initiated Dedicated Bearer Deactivation procedure (sub-clause 5.4.4.2) for the GBR bearer(s) of the 
UE after the S 1 Release procedure is completed. 

Editor's note: FES: Other causes of SI release (in addition to user inactivity) that should lead to the preservation of 
the GBR bearer(s). 



5.3.6 Void 
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5.3.7 GUTI Reallocation procedure 

The MME may initiate the GUTI Reallocation procedure to reallocate the GUTI and/or TAI list at any time when a 
signalling association is established between UE and MME. The GUTI Reallocation procedure allocates a new GUTI 
and/or a new TAI list to the UE. The GUTI and/or the TAI list may also be reallocated by the Attach or the Tracking 
Area Update procedures. 

The GUTI Reallocation procedure is illustrated in Figure 5.3.7-1. 




Figure 5.3.7-1: GUTI Reallocation Procedure 

1. The MME sends GUTI Reallocation Command (GUTI, TAI list) to the UE. 

2. The UE returns GUTI Reallocation Complete message to the MME. 

5.3.8 Detach procedure 

5.3.8.1 General 

The Detach procedure allows: 

- the UE to inform the network that it does not want to access the EPS any longer, and 

- the network to inform the UE that it does not have access to the EPS any longer. 
The UE is detached either explicitly or implicitly: 

- Explicit detach: The network or the UE explicitly requests detach and signal with each other. 

- Implicit detach: The network detaches the UE, without notifying the UE. This is typically the case when the 
network presumes that it is not able to communicate with the UE, e.g. due to radio conditions. 

Three detach procedures are provided when the UE accesses the EPS through E-UTRAN. The first detach procedure is 
UE-initiated detach procedure and other detach procedures are network-initiated detach procedure: 

- UE-Initiated Detach Procedure; 
MME-Initiated Detach Procedure; 

- HSS -Initiated Detach Procedure. 

Editor's Note: These procedures should cover the case that detach is required because the UE is attached to a non- 
3GPP RAT, these procedures need to be updated according to later conclusions. 

5.3.8.2 UE-initiated Detach procedure 

The Detach procedure when initiated by the UE is illustrated in Figure 5.3.8.2-1. 



ETSI 



3GPP TS 23.401 version 8.2.0 Release 8 



78 



ETSI TS 123 401 V8.2.0 (2008-10) 



UE 



eNodeB 



MME 



SGSN 



Serving GW 



PDN GW 



PCRF 



1 ■ Detach Request 



1 1 . Detach Accept 



12. Signalling Connection Release 



2. Delete Bearer Request 



3. Delete Bearer Response 



4. Detach Indication 



5. Delete Bearer Request 



_9JDelete 

10. Detach lihdication Ack 



JDelete Bear(5r Response 



6. Delete Beare r Request 

7. Delete Bearer Response 



8. PCEF Initiatec) 
Session Term 



HSS 



IP-CAN 
nation 

(A) 



Figure 5.3.8.2-1: UE-lnitiated Detach Procedure 

NOTE 1: For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402 [2]. Steps 6, 7 and 8 concern GTP 
based S5/S8 

NOTE 2: When multiple PDN connections are active, parts of this procedure are repeated. 

1. The UE sends NAS message Detach Request (GUTI, Switch Off) to the MME. This NAS message is used to 
trigger the establishment of the SI connection if the UE was in ECM-IDLE mode. Switch Off indicates whether 
detach is due to a switch off situation or not. 

NOTE 3: Security procedures may be invoked if the NAS message is used to establish the SI connection. 

2. The active EPS Bearers in the Serving GW regarding this particular UE are deactivated by the MME sending 
Delete Bearer Request (TEID) to the Serving GW. 

3. The Serving GW acknowledges with Delete Bearer Response (TEID). If ISR is not activated, this step shall be 
executed after step 7. 

4. If ISR is activated, MME sends Detach Indication (IMSI) message to the associated SGSN. 

5. The active PDP contexts in the Serving GW regarding this particular UE are deactivated by the SGSN sending 
Delete Bearer Request (TEID) to the Serving GW. 

6. The Serving GW sends Delete Bearer Request (TEID) to the PDN GW. If ISR is not activated, this step shall be 
triggered by step 2. 

Editor's note: If ISR is activated, it is FES step 6 is triggered by step 2 or step 5 (after both the bearers of EUTRAN 
and 2G/3G are requested to be deleted). 

7. The PDN GW acknowledges with Delete Bearer Response (TEID). 

8. The PDN GW employs a PCEF initiated IP-CAN Session Termination Procedure as defined in TS 23.203 [6] 
with the PCRF to indicate to the PCRF that EPS Bearer is released if PCRF is applied in the network. 

9. The Serving GW acknowledges with Delete Bearer Response (TEID). 

10. The SGSN sends Detach Indication Acknowledge message to the MME. 

1 1. If Switch Off indicates that detach is not due to a switch off situation, the MME sends a Detach Accept to the 
UE. 
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12. The MME releases the Sl-MME signalling connection for the UE by sending SI Release Command to the 

eNodeB with Cause = Detach. The details of this step are covered in the "SI Release Procedure", as described in 
clause 5.3.5. 



5.3.8.3 MME-initiated Detach procedure 

The MME-Initiated Detach procedure when initiated by the MME is illustrated in Figure 5.3.8.3-1. 
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Figure 5.3.8.3-1: MME-Initiated Detach Procedure 



NOTE 1: For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402 [2]. Steps 3, 4 and 5 concern GTP 
based S5/S8. 

NOTE 2: When multiple PDN connections are active, parts of this procedure are repeated. 

1 . The MME initiated detach procedure is either explicit or implicit. The MME may impHcitly detach a UE, if it 
has not had communication with UE for a long period of time. The MME does not send the Detach Request 
(Detach Type) message to the UE in case of implicit detach. The MME may explicitly detach the UE by sending 
a Detach Request message to the UE. The Detach Type may be set to re-attach in which case the UE should re- 
attach at the end of the detach process. 

2. Any EPS Bearers in the Serving GW regarding this particular UE are deactivated by the MME sending Delete 
Bearer Request (TEID) message to the Serving GW. 

3. The Serving GW sends a Delete Bearer Request (TEID) message to the PDN GW. 

4. The PDN GW acknowledges with Delete Bearer Response (TEID) message. 

5. The PDN GW employs an IP-CAN Session Termination procedure as defined in TS 23.203 [6] with the PGRF to 
indicate to the PGRF that the EPS Bearer(s) are released if a PGRF is configured. 

6. The Serving GW acknowledges with Delete Bearer Response (TEID) message. 

7. If the UE receives the Detach Request message from the MME in the step 1, the UE sends a Detach Accept 
message to the MME any time after step 1. 

8. After receiving the Detach Accept message, if Detach Type did not request the UE to make a new attach, the 
MME releases the Sl-MME signalHng connection for the UE by sending an SI Release Command (Cause) 
message to the eNodeB with Cause set to Detach. The details of this step are covered in the "SI Release 
Procedure", as described in clause 5.3.5. 
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5.3.8.4 HSS-initiated Detach procedure 

The HSS -Initiated Detach procedure is initiated by the HSS. The HSS uses this procedure for operator-determined 
purposes to request the removal of a subscriber's MM and EPS bearer at the MME. 

It is FFS, if the HSS initiates a detach procedure to update the subscriber's MM context at the MME and to delete the 
EPS bearer because that the UE's accessing RAT is changed from 3GPP to Non-3GPP. 

The HSS-Initiated Detach Procedure is illustrated in Figure 5.3.8.4-1. 
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Figure 5.3.8.4-1: HSS-Initiated Detach Procedure 



HSS 



NOTE 1: For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402 [2]. Steps 4, 5 and 6 concern GTP 
based S5/S8. 

NOTE 2: When multiple PDN connections are active, parts of this procedure are repeated. 

1. If the HSS wants to request the immediate deletion of a subscriber's MM contexts and EPS Bearers, the HSS 
shall send a Cancel Location (IMSI, Cancellation Type) message to the MME with Cancellation Type set to 
Subscription Withdrawn. 

It is FFS whether the Cancellation type can be set to "implicit detach because of UE's accessing RAT changed from 
3GPP to Non-3GPP". 

2. If Cancellation Type is Subscription Withdrawn, the MME informs the UE, that it has been detached, by sending 
Detach Request message to the UE. 

3. The EPS Bearers in the Serving GW regarding this particular UE are deactivated by the MME sending a Delete 
Bearer Request (TEID) message to the Serving GW. 

4. The Serving GW sends Delete Bearer Request (TEID) message to the PDN GW. 

Editor's note: If ISR is activated, step 4 may be triggered after both the bearers of EUTRAN and 2G/3G are 
requested to be deleted, FFS. 

5. The PDN GW acknowledges with Delete Bearer Response (TEID) message. 

It is FFS, If the Cancellation type is set to "implicit detach because of UE's accessing RAT changed from 3GPP to 
Non-3GPP", after the PDN deletes the EPS Bearer, the PDN GW should not release the UE's PDP address of the 
Bearer. If the Cancellation type is set to "Subscription Withdrawn", after the PDN deletes the EPS Bearer, the PDN GW 
should release the UE's PDP address of the Bearer and assign the PDP address to other UE. 

6. The PDN GW employs a PCEF initiated IP-CAN Session Termination procedure as defined in TS 23.203 [6] 
with the PCRF to indicate to the PCRF that the EPS bearer is released if a PCRF is configured. 
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7. The Serving GW acknowledges with Delete Bearer Response (TEID) message. 

8. If the UE receives the Detach Request message from the MME, the UE sends a Detach Accept message to the 
MME any time after step 2. 

9. The MME confirms the deletion of the MM contexts and the EPS Bearer(s) with a Cancel Location Ack (IMSI) 
message. 

10. After receiving the Detach Accept message, the MME releases the SI -MME signalling connection for the UE by 
sending SI Release Conmiand (Cause) message to the eNodeB with Cause set to Detach. The details of this step 
are covered in the "SI Release Procedure", as described in clause 5.3.5. 

NOTE 3: Steps 2,8,10 are only for the Cancellation type is set to Subscription Withdrawn. 

5.3.9 HSS User Profile management function procedure 

5.3.9.1 General 

The HSS user profile management function allows the HSS to update the HSS user profile stored in the MME. 
Whenever the HSS user profile is changed for a user in the HSS, and the changes affect the HSS user profile stored in 
the MME, the MME shall be informed about these changes by the means of the following procedure: 

- Insert HSS User Profile procedure, used to add or modify the HSS user profile in the MME. 

5.3.9.2 Insert Subscriber Data procedure 

The Insert Subscriber Data procedure is illustrated in Figure 5.3.9.2-1. 
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Figure 5.3.9.2-1 : Subscriber Data procedure 

1. The HSS sends an Insert Subscriber Data (IMSI, Subscription Data) message to the MME. 

2. The MME updates the stored Subscription Data and acknowledges the Insert Subscriber Datamessage by 
returning an Insert Subscriber DataAck (IMSI) message to the HSS. The update result should be contained in the 
Ack message. The MME compares the PDN subscription contexts contained in the Subscription Datareceived 
from the HSS with the PDN subscription contexts the MME stores and the MME performs following action: 

- For received PDN subscription contexts that have no related active EPS bearer in the MME, no further action 
is required except storage in the MME. 

- For received PDN subscription contexts with a related active EPS bearer, the MME shall in addition compare 
the received updated PDN subscription context with the existing data for that EPS bearer and take actions. 
MME initiated bearer deactivation could be triggered if VPLMN address is not allowed. If QoS subscribed 
has changed, e.g. AMBR, and UE is in the ECM-CONNECTED state, an EPS bearer modification procedure 
shall be triggered. If QoS subscribed has changed and when UE is not in the ECM-CONNECTED state or the 
EPS bearer modification is not successful when UE is in the ECM-CONNECTED state: 



ETSI 



3GPP TS 23.401 version 8.2.0 Release 8 



82 



ETSI TS 123 401 V8.2.0 (2008-10) 



a) If ISR is activated when the next activity from UE is detected the MME shall compare the stored updated 
subscription data with the existing data for that EPS bearer and initiate EPS bearer modification 
procedure. 

b) If ISR is not activated, the MME should directly delete the concerned EPS bearer. 

If other Subscription Data are changed compared to the Subscription Data stored by the MME before 
receiving the Insert Subscriber Data the MME initiates appropriate action, e.g. if roaming restrictions are 
modified the MME initiated detach could be triggered. 

It is FES whether a specific HSS User Profile Delete procedure is needed similar to "Delete User Profile" 
procedure in TS 23.060 [7]. If such a procedure is needed, then the HSS should send the IMSI as well as the 
PDN subscription context identifiers list so that the MME may trigger the corresponding EPS bearer deactivation 
procedure. This procedure may be needed when HSS replaces unsupported services in an MME and as a 
consequence the MME deactivates affected active EPS bearers. 

5.3.9.3 Purge function 

The Purge function allows an MME to inform the HSS that it has deleted the subscription data and MM context of a 
detached MS. The MME may, as an implementation option, delete the subscription data and MM context of an UE 
immediately after the implicit or explicit detach of the UE. Alternatively the MME may keep for some time the 
subscription data and the MM context of the detached UE, so that the data can be reused at a later attach without 
accessing the HSS. 
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^ 2. Purge UE Acknowledge 











Figure 5.3.9.3-1 : Purge Procedure 

1 . After deleting the Subscription data and MM contexts of a detached UE, the MME sends Purge UE (IMSI) 
message to the HSS. 

2. The HSS sets the UE Purged for E-UTRAN flag and acknowledges with a Purge UE Ack message. 

5.3.10 Security Function 
5.3.10.1 General 

The security functions include: 
The security functions include: 

- Guards against unauthorised EPS service usage (authentication of the UE by the network and service request 
validation). 

- Provision of user identity confidentiality (temporary identification and ciphering). 

- Provision of user data and signalling confidentiality (ciphering). 

- Provision of origin authentication of signalling data (integrity protection). 

- Authentication of the network by the UE. 

Security-related network functions for EPS are described in TS 33.401 [41]. 
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5.3.1 0.2 Authentication and Key Agreement 

EPS AKA is the authentication and key agreement procedure that shall be used over E-UTRAN, between the UE and 
MME. EPS AKA is specified in TS 33.102 [40]. 

5.3.1 0.3 User Identity Confidentiality 

An M-TMSI identifies a user between the UE and the MME. The relationship between M-TMSI and IMSI is known 
only in the UE and in the MME. 

5.3.1 0.4 User Data and Signalling Confidentiality 

There are two different levels of the security associations between the UE and the network. 

i) RRC and UP security association is between the UE and eUTRAN. The RRC security associations protect the 
RRC signalling between the UE and eUTRAN (integrity protection and ciphering). The UP security association 
is also between the UE and eUTRAN and provide user plane encryption function. 

ii) NAS security association is between the UE and the MME. It provides integrity protection and encryption of 
NAS signalHng. 

5.3.1 0.4.1 AS security mode command procedure 

The MME triggers the AS security mode command procedure to enable ciphering of the UP traffic and ciphering and 
integrity protection of the RRC signalling as described in TS 33.401 [41]. 

Editor's note: It is FES whether the AS security mode command procedure represents a stand-alone procedure or 
whether it can be combined with other signalling messages. 

5.3.10.4.2 NAS Security Mode Command procedure 

The MME uses the NAS security mode command procedure to establish a NAS security association between the UE 
and MME, in order to protect the further NAS signalling messages. More details of the procedure are described in 
TS 33.401 [41]. 

Editor's note: It is FES whether the NAS security mode command procedure represents a stand-alone procedure or 
whether it can be combined with other signalling messages. 

5.3.1 0.5 ME identity check procedure 

Editor's note: The term Mobile Equipment Identity is used in this text so as to indicate that the EPC should support 
multiple equipment identity formats (e.g. those from 3GPP2, WiMAX, etc) as well as the IMEISV 

Editor's note: The development of a Global EIR concept might require refinement of these procedures. 

The Mobile Equipment Identity Check Procedure permits the operator(s) of the MME and/or the HSS and/or the PDN- 
GW to check the Mobile Equipment's identity (e.g. to check that it has not been stolen, or, to verify that it does not have 
faults). 

The ME Identity can be checked by the MME passing it to an Equipment Identity Register (EIR) and then the MME 
analysing the response from the EIR in order to determine its subsequent actions (e.g. sending an Attach Reject if the 
EIR indicates that the Mobile Equipment is blacklisted). 

The ME identity check procedure is illustrated in Figure 5.3.10.5-1. 
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Figure 5.3.10.5-1 : Identity Check Procedure 

1 . The MME sends Identity Request (Identity Type) to the UE. The UE responds with Identity Response (Mobile 
Identity). 

2. If the MME is configured to check the IMEI against the EIR, it sends ME Identity Check (ME Identity, IMSI) to 
EIR. The EIR responds with ME Identity Check Ack (Result). 

NOTE: The Identity Check Procedure is typically executed as part of the Attach procedure (see clause 5.3.2.1). 

For roaming situations, in order to permit the HPLMN operator to check the ME Identity, the VPLMN shall obtain the 
ME identity at Initial Attach when Attach Type does not indicate handover, and, at Tracking Area Update from 
UTRAN/GERAN if the old SGSN does not provide the ME Identity. In order to minimise signalling delays during these 
procedures, the MME should obtain the ME Identity during the EPC Authentication and Ciphering procedure. (FES) 

At Initial Attach when Attach Type does not indicate handover, the MME includes the ME Identity in the Update 
Location message to the HSS. 

NOTE: It is FES whether the mechanisms by which the HSS and/or PDN-GW check the ME Identity are to be 
standardised in this release of the 3GPP specifications. 



5.4 Session Management, QoS and interaction witli PCC 
functionality 

5.4.1 Dedicated bearer activation 

The dedicated bearer activation procedure for a GTP based S5/S8 is depicted in figure 5.4.1-1. 
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Figure 5.4.1-1: Dedicated Bearer Activation Procedure 



NOTE 1: Steps 3-8 are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. For an 
PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Steps 1, 2, 9 and 10 
concern GTP based S5/S8. 



1. If dynamic PCC is deployed, the PCRF sends a PCC decision provision (QoS poHcy) message to the PDN GW. 
This corresponds to the initial steps of the PCRF-Initiated IP-CAN Session Modification procedure as defined in 
TS 23.203 [6], up to the point that the PDN GW requests IP-CAN Bearer SignaUing. If dynamic PCC is not 
deployed, the PDN GW may apply local QoS policy. 

2. The PDN GW uses this QoS policy to assign the EPS Bearer QoS, i.e., it assigns the values to the bearer level 
QoS parameters (excluding AMBR); see clause 4.7.3. The PDN GW sends a Create Dedicated Bearer Request 
message (IMSI, PTI, EPS Bearer QoS, UL TFT, S5/S8 TEID, LBI) to the Serving GW, the Linked EPS Bearer 
Identity (LBI) is the EPS Bearer Identity of the default bearer. The Procedure Transaction Id (PTI) parameter is 
only used when the procedure was initiated by a UE Requested Bearer Resource Allocation Procedure - see 
clause 5.4.5. 

3. The Serving GW sends the Create Dedicated Bearer Request (IMSI, PTI, EPS Bearer QoS, UL TFT, Sl-TEID, 
LBI, DL TFT (for PMIP-based S5/S8)) message to the MME. If the UE is in ECM-IDLE state the MME will 
trigger the Network Triggered Service Request from step 3 (which is specified in clause 5.3.4.3). In that case the 
following steps 4-7 may be combined into Network Triggered Service Request procedure or be performed 
standalone. It is FES in case there is no paging response. 

4. The MME selects an EPS Bearer Identity, which has not yet been assigned to the UE. The MME then builds a 
Session Management Configuration IE including the PTI, UL TFT, EPS Bearer QoS parameters (excluding 
ARP), the EPS Bearer Identity and the Linked EPS Bearer Identity (LBI). If the UE has UTRAN or GERAN 
capabilities, the MME uses the EPS bearer QoS information to derive the corresponding PDP context parameters 
QoS Negotiated (R99 QoS profile). Radio Priority and Packet Flow Id and includes them in the Session 
Management Configuration. If the UE indicated in the UE Network Capability it does not support BSS packet 
flow procedures, then the MME shall not include the Packet Flow Id. The MME then signals the Bearer Setup 
Request (EPS Bearer QoS, Session Management Configuration, Sl-TEID) message to the eNodeB. 

5. The eNodeB maps the EPS Bearer QoS to the Radio Bearer QoS. It then signals a RRC Connection 
Reconfiguration (Radio Bearer QoS, Session Management Configuration, EPS RB Identity) message to the UE. 
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The UE shall store the QoS Negotiated, Radio Priority, Packet Flow Id, which it received in the Session 
Management Configuration, for use when accessing via GERAN or UTRAN. The UE NAS stores the EPS 
Bearer Identity and links the dedicated bearer to the default bearer indicated by the Linked EPS Bearer Identity 
(LB I). The UE uses the uplink packet filter (UL TFT) to determine the mapping of service data flows to the radio 
bearer. The UE may provide the EPS Bearer QoS parameters to the application handling the service data flow. 
The application usage of the EPS Bearer QoS is implementation dependent. The UE shall not reject the RRC 
Connection Reconfiguration on the basis of the EPS Bearer QoS parameters contained in the Session 
Management Configuration IE. 

NOTE 2: The details of the Radio Bearer QoS are specified in TS 36.300 [5]. 

6. The UE NAS layer builds a Session Management Response IE including the EPS Bearer Identity. The UE then 
acknowledges the radio bearer activation to the eNodeB with a RRC Connection Reconfiguration Complete 
(Session Management Response) message. 

7. The eNodeB acknowledges the bearer activation to the MME with a Bearer Setup Response (EPS Bearer 
Identity, Sl-TEID, Session Management Response) message. The eNodeB indicates whether the requested EPS 
Bearer QoS could be allocated or not. 

8. The MME acknowledges the bearer activation to the Serving GW by sending a Create Dedicated Bearer 
Response (EPS Bearer Identity, Sl-TEID) message. 

9. The Serving GW acknowledges the bearer activation to the PDN GW by sending a Create Dedicated Bearer 
Response (EPS Bearer Identity, S5/S8-TEID) message. 

10. If the dedicated bearer activation procedure was triggered by a PCC Decision Provision message from the PCRF, 
the PDN GW indicates to the PCRF whether the requested PCC decision (QoS policy) could be enforced or not, 
allowing the completion of the PCRF-Initiated IP-CAN Session Modification procedure as defined in 

TS 23.203 [6], preceding after the completion of IP-CAN bearer signalling. 

NOTE 3: The exact signalling of step 1 and 10 (e.g. in case of local break-out) is outside the scope of this 

specification. This signalling and its interaction with the dedicated bearer activation procedure are to be 
specified in TS 23.203 [6]. Steps 1 and 10 are included here only for completeness. 

5.4.2 Bearer modification with bearer QoS update 

5.4.2.1 PDN GW initiated bearer modification with bearer QoS update 

The PDN-GW initiated bearer modification procedure (including EPS Bearer QoS update and APN-AMBR) for a GTP 
based S5/S8 is depicted in figure 5.4.2.1-1. In this procedure, the UE is assumed to be in active mode. 
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Figure 5.4.2.1-1 : Bearer Modification Procedure with Bearer QoS Update, UE in active mode 

NOTE 1: Steps 3-8 are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. For a 
PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Steps 1, 2, 9 and 10 
concern GTP based S5/S8. 



1. If dynamic PCC is deployed, the PCRF sends a PCC decision provision (QoS poHcy) message to the PDN GW. 
This corresponds to the initial steps of the PCRF-Initiated IP-CAN Session Modification procedure as defined in 
TS 23.203 [6], up to the point that the PDN GW requests IP-CAN Bearer SignaUing. If dynamic PCC is not 
deployed, the PDN GW may apply local QoS policy. 

2. The PDN GW uses this QoS policy to determine that the authorized QoS of a service data flow has changed or 
that a service data flow shall be aggregated to or removed from an active bearer. The PDN GW generates the UL 
TFT and updates the EPS Bearer QoS to match the aggregated set of service date flows. The PDN GW then 
sends the Update Bearer Request (PTI, EPS Bearer Identity, EPS Bearer QoS, APN-AMBR, UL TFT) message 
to the Serving GW. The Procedure Transaction Id (PTI) parameter is used when the procedure was initiated by a 
UE Requested Bearer Resource Allocation Procedure - see clause 5.4.5 or is used when the procedure was 
initiated by a UE Requested Bearer Resource Release Procedure - see clause 5.4.6. For APN-AMBR, the EPS 
bearer identity must refer to a non-GBR bearer. 

3. The Serving GW sends the Update Bearer Request (PTI, EPS Bearer Identity, EPS Bearer QoS, UL TFT, 
APN-AMBR, DL TFT (for PMIP-based S5/S8)) message to the MME. If the UE is in ECM-IDLE state the 
MME will trigger the Network Triggered Service Request from step 3 (which is specified in clause 5.3.4.3). In 
that case the following steps 4-7 may be combined into Network Triggered Service Request procedure or be 
performed standalone. It is FES in case there is no paging response. 

4. The MME builds a Session Management Configuration IE including the PTI, EPS Bearer QoS parameters 
(excluding ARP), UL TFT, APN-AMBR and EPS Bearer Identity. If the UE has UTRAN or GERAN 
capabilities, the MME uses the EPS Bearer QoS information to derive the corresponding PDP context 
parameters QoS Negotiated (R99 QoS profile). Radio Priority and Packet Flow Id and includes them in the 
Session Management Configuration. If the UE indicated in the UE Network Capability it does not support BSS 
packet flow procedures, then the MME shall not include the Packet Flow Id. If the APN-AMBR has changed the 
MME may update the used UE-AMBR if appropriate. The MME then sends the Bearer Modify Request (EPS 
Bearer Identity, EPS Bearer QoS, Session Management Configuration, UE-AMBR) message to the eNodeB. 

5. The eNodeB maps the modified EPS Bearer QoS to the Radio Bearer QoS. It then signals a Radio Bearer 
Modify Request (Radio Bearer QoS, Session Management Configuration, EPS RB Identity) message to the UE. 
The UE shall store the QoS Negotiated, Radio Priority, Packet Flow Id, which it received in the Session 
Management Configuration, for use when accessing via GERAN or UTRAN. The UE uses the uplink packet 
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filter (UL TFT) to determine the mapping of service data flows to the radio bearer. The UE may provide EPS 
Bearer QoS parameters to the application handling the service data flow. The application usage of the EPS 
Bearer QoS is implementation dependent. The UE shall not reject the Radio Bearer Modify Request on the basis 
of the EPS Bearer QoS parameters contained in the Session Management Configuration IE. 

NOTE 2: The details of the Radio Bearer QoS are specified in TS 36.300 [5]. 

6. The UE NAS layer builds a Session Management Response IE including EPS Bearer Identity. The UE then 
acknowledges the radio bearer modification to the eNodeB with a Radio Bearer Modify Response (Session 
Management Response) message. 

7. The eNodeB acknowledges the bearer modification to the MME with a Bearer Modify Response (EPS Bearer 
Identity, Session Management Response) message. With this message, the eNodeB indicates whether the 
requested EPS Bearer QoS could be allocated or not. 

8. The MME acknowledges the bearer modification to the Serving GW by sending an Update Bearer Response 
(EPS Bearer Identity) message. 

9. The Serving GW acknowledges the bearer modification to the PDN GW by sending an Update Bearer Response 
(EPS Bearer Identity) message. 

10. If the Bearer modification procedure was triggered by a PCC Decision Provision message from the PCRF, the 
PDN GW indicates to the PCRF whether the requested PCC decision (QoS policy) could be enforced or not by 
sending a Provision Ack message allowing the completion of the PCRF-Initiated IP-CAN Session Modification 
procedure as defined in TS 23.203 [6], proceding after the completion of IP-CAN bearer signalling. 

NOTE 3: The exact signalling of step 1 and 10 (e.g. in case of local break-out) is outside the scope of this 

specification. This signalling and its interaction with the bearer activation procedure are to be specified in 
TS 23.203 [6]. Steps 1 and 10 are included here only for completeness. 

5.4.2.2 HSS Initiated Subscribed QoS Modification 

The HSS Initiated Subscribed QoS Modification for a GTP-based S5/S8 is depicted in figure 5.4.2.2-1. 

If the APN-AMBR of the subscribed QoS has changed, the MME updates the APN-AMBR. The EPS bearer identity for 
APN-AMBR changes must refer to a non-GBR bearer. 
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Figure 5.4.2.2-1 : HSS Initiated Subscribed QoS IVIodification 

NOTE: For a PMIP-based S5/S8, procedure steps (A) and steps (B) are defined in TS 23.402 [2]. Steps 3, 4, 5 
and 7 concern GTP based S5/S8. 

1. The HSS sends an Insert Subscriber Data (IMSI, Subscription Data) message to the MME (see clause 5.3.9.2). 

2. The MME sends the Update Bearer Request (EPS Bearer Identity, Bearer QoS, APN-AMBR) message to the 
Serving GW. The EPS Bearer Identity identifies the default bearer. The EPS Bearer QoS contains the EPS 
subscribed QoS profile to be updated. 

3. The Serving GW sends the Update Bearer Request (EPS Bearer Identity, EPS Bearer QoS, APN-AMBR) 
message to the PDN GW. 

4. If PCC infrastructure is deployed, the PDN GW informs the PCRF about the bearer QoS update. The PCRF 
sends new updated PCC decision to the PDN GW. This corresponds to the PCEF-initiated IP-CAN Session 
Modification procedure as defined in TS 23.203 [6]. 

5. The PDN GW then sends the Update Bearer Request (PTI, EPS Bearer Identity, EPS Bearer QoS, UL TFT, 
APN-AMBR) message to the Serving GW. 

6. Steps between 2 and 9, as described in clause 5.4.2.1, are invoked. 

7. The Serving GW acknowledges the bearer modification to the PDN GW by sending an Update Bearer Response 
(EPS Bearer Identity) message. 

8. The PDN GW indicates to the PCRF whether the requested PCC decision was enforced or not by sending a 
Provision Ack message. 



5.4.3 Bearer modification without bearer QoS update 

The bearer modification procedure without QoS update is used to update the UL TFT for an active default or dedicated 
bearer. This procedure for a GTP based S5/S8 is depicted in figure 5.4.3-1. 
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Figure 5.4.3-1 : Bearer Modification Procedure without Bearer QoS Update 



NOTE 1: Steps 3-8 are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. For an 
PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Steps 1, 2, 9 and 10 
concern GTP based S5/S8. 

1. If dynamic PCC is deployed, the PCRF sends a PCC decision provision (QoS poHcy) message to the PDN GW. 
This corresponds to the beginning of the PCRF-initiated IP-CAN Session Modification procedure as defined in 
TS 23.203 [6], up to the point that the PDN GW requests IP-CAN Bearer SignalHng. If dynamic PCC is not 
deployed, the PDN GW may apply local QoS policy. 

2. The PDN GW uses this QoS policy to determine that a service data flow shall be aggregated to or removed from 
an active bearer. The PDN GW generates the UL TFT and determines that no update of the Bearer QoS is 
needed. The PDN GW then sends the Update Bearer Request (PTI, EPS Bearer Identity, UL TFT) message to 
the Serving GW. The Procedure Transaction Id (PTI) parameter is used when the procedure was initiated by a 
UE Requested Bearer Resource Allocation procedure - see clause 5.4.5 or is used when the procedure was 
initiated by a UE Requested Bearer Resource Release Procedure - see clause 5.4.6. 

3. The Serving GW sends the Update Bearer Request (PTI, EPS Bearer Identity, UL TFT, DL TFT (for PMIP- 
based S5/S8)) message to the MME. If the UE is in ECM-IDLE state the MME will trigger the Network 
Triggered Service Request from step 3 (which is specified in clause 5.3.4.3). In that case the following steps 4-7 
may be combined into Network Triggered Service Request procedure or be performed standalone. It is FES in 
case there is no paging response. 

4. The MME builds a Session Management Configuration IE including the UL TFT and EPS Bearer Identity. The 
MME then sends a Downlink NAS Transport (Session Management Configuration) message to the eNodeB. 

5. The eNodeB sends the Direct Transfer (Session Management Configuration) message to the UE. The UE uses 
the uplink packet filter (UL TFT) to determine the mapping of service data flows to the radio bearer. 

6. The UE NAS layer builds a Session Management Response including EPS Bearer Identity. The UE then sends a 
Direct Transfer (Session Management Response) message to the eNodeB. 

7. The eNodeB sends an Uplink NAS Transport (Session Management Response) message to the MME. 

8. The MME acknowledges the bearer modification to the Serving GW by sending an Update Bearer Response 
(EPS Bearer Identity) message. 
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9. The Serving GW acknowledges the bearer modification to the PDN GW by sending an Update Bearer Response 
(EPS Bearer Identity) message. 

10. If the bearer modification procedure was triggered by a FCC Decision Provision message from the PCRF, the 
PDN GW indicates to the PCRF whether the requested PCC decision (QoS policy) could be enforced or not by 
sending a Provision Ack message. This then allows the PCRF-Initiated IP-CAN Session Modification procedure 
as defined in TS 23.203 [6] to continue and eventually conclude, proceding after the completion of IP-CAN 
bearer signalling. 

NOTE 2: The exact signalHng of step 1 and 10 (e.g. in case of local break-out) is outside the scope of this 

specification. This signalling and its interaction with the bearer activation procedure are to be specified in 
TS 23.203 [6]. Steps 1 and 10 are included here only for completeness. 

5.4.4 Bearer deactivation 



5.4.4.1 



PDN GW initiated bearer deactivation 



The bearer deactivation procedure for a GTP based S5/S8 is depicted in figure 5.4.4.1-1. In this procedure, the UE is 
assumed to be in ECM-CONNECTED. This procedure can be used to deactivate a dedicated bearer or deactivate all 
bearers belonging to a PDN address. 
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Figure 5.4.4.1-1: PDN GW Initiated Bearer Deactivation, UE in active mode 



NOTE 1: Steps 3-8 are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. For an 
PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Steps 1, 2, 9 and 10 
concern GTP-based S5/S8. 

1. If dynamic PCC is not deployed, The PDN GW is triggered to initiate the Bearer Deactivation procedure due 
either a QoS poHcy or on request from the MME (as outHned in clause 5.4.4.2). Optionally, the PCRF sends QoS 
policy to the PDN GW. This corresponds to the initial steps of the PCRF-initiated IP-CAN Session Termination 
procedure as defined in TS 23.203 [6], up to the point that the PDN GW requests IP-CAN Bearer Signalling. If 
dynamic PCC is not deployed, the PDN GW may apply local QoS policy. The PDN GW initiated Bearer 
deactivation is also performed when handovers without optimization occurs from 3 GPP to non-3 GPP, in which 
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case, the default bearer and all the dedicated bearers associated with the PDN address are released, but the PDN 
address is kept in the PDN GW. 

2. The PDN GW sends a Delete Bearer Request (PTI, EPS Bearer Identity, Causes) message to the Serving GW. 
The Procedure Transaction Id (PTI) parameter in this step and in the following steps is only used when the 
procedure was initiated by a UE Requested Bearer Resource Release Procedure - see clause 5.4.6. This message 
can include an indication that all bearers belonging to that PDN connection shall be released. The PDN GW 
includes 'Cause' IE in the Delete Bearer Request message and sets the IE to 'RAT changed from 3GPP to Non- 
3GPP' if the Delete Bearer Request message is caused by handover without optimization occurs from 3GPP to 
non-3GPP. 

3a. The Serving GW sends the Delete Bearer Request (PTI, EPS Bearer Identity, Cause) message to the MME. This 
message can include an indication that all bearers belonging to that PDN connection shall be released. 

3b. If ISR is activated, the Serving GW sends the Delete Bearer Request (PTI, EPS Bearer Identity, Cause) message 
to the SGSN. This message can include an indication that all bearers belonging to that PDN connection shall be 
released, and the SGSN releases all bearer resources of the PDN connection. 

NOTE 2: If all the bearers belonging to a UE are released due to handover without optimization occurs from 3 GPP 
to non-3GPP, the SGSN changes the MM state of the UE to IDLE (GERAN network) or PMM- 
DET ACHED (UTRAN network). 

4. If the release of the bearer in E-UTRAN has already been signalled to the MME, steps 4-7 are omitted. 
Otherwise the MME builds a Session Management Configuration IE including the PTI, a Deletion Indicator and 
EPS Bearer Identity. The MME then signals the Deactivate Bearer Request (EPS Bearer Identity, Session 
Management Configuration) message to the eNodeB. 

5. The eNodeB signals a Radio Bearer Release Request (EPS RB Identity, Session Management Configuration) 
message to the UE. 

6. The UE NAS removes the UL TFTs and EPS Bearer Identity according to the Session Management 
Configuration. The UE NAS then layer builds a Session Management Response including the EPS Bearer 
Identity. The UE then acknowledges the radio bearer release to the eNodeB with a Radio Bearer Release 
Response (Session Management Response)message. 

7. The eNodeB acknowledges the bearer deactivation to the MME with a Deactivate Bearer Response (EPS Bearer 
Identity, Session Management Response) message. 

8a. The MME deletes the bearer context related to the deactivated EPS bearer acknowledges the bearer deactivation 
to the Serving GW by sending a Delete Bearer Response (EPS Bearer Identity) message. 

8b The SGSN deletes PDP Context related to the deactivated EPS bearer and acknowledges the bearer deactivation 
to the Serving GW by sending a Delete Bearer Response (EPS Bearer Identity) message. 

9. If ISR is active, after receiving the two Delete Bearer Response messages from the MME and the SGSN, or if 
ISR is not active, after receiving the Delete Bearer Response messages from the MME, the Serving GW deletes 
the bearer context related to the deactivated EPS bearer acknowledges the bearer deactivation to the PDN GW by 
sending a Delete Bearer Response (EPS Bearer Identity) message. 

10. The PDN GW deletes the bearer context related to the deactivated EPS bearer. If the dedicated bearer 
deactivation procedure was triggered by a PCC Decision Provision message from the PCRF, the PDN GW 
indicates to the PCRF whether the requested PCC decision was successfully enforced by completing the PCRF- 
initiated IP-CAN Session Termination procedure as defined in TS 23.203 [6], proceding after the completion of 
IP-CAN bearer signalling. 

NOTE 3: The exact signalling of step 1 and 10 (e.g. in case of local break-out) is outside the scope of this 

specification. This signalling and its interaction with the dedicated bearer activation procedure are to be 
specified in TS 23.203 [6]. Steps 1 and 10 are included here only for completeness. 

Steps 4 to 7 are not performed when the UE is in ECM-IDLE. The EPS bearer state is synchronized between the 
UE and the network at the next ECM-IDLE to ECM-CONNECTED transition (e.g. Service Request or TAU 
procedure). 

If all the bearers belonging to a UE are released, the MME shall change the MM state of the UE to EMM- 
DEREGISTERED and the MME sends the SI Release Command to the eNodeB, which initiates the release of 
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the RRC connection for the given UE if it is not released yet, and returns an S 1 Release Complete message to the 
MME. 

If the UE detects that all of its bearers are released, the UE shall also change the MM state to EMM- 
DEREGISTERED. 

Editor's note: FES: handhng of steps 4 to 7 when the UE is in ECM-CONNECTED but not reachable. 

5.4.4.2 MME Initiated Dedicated Bearer Deactivation 

MME initiated Dedicated Bearer Deactivation is depicted in Figure 5.4.4-2 below. This procedure deactivates dedicated 
bearers. Default bearers are not affected. 
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Figure 5.4.4.2-1: MME-initiated Dedicated Bearer Deactivation 

NOTE: For a PMIP-based S5/S8, procedure steps (A) and steps (B) are defined in TS 23.402 [2]. Steps 3, 4, 5 
and 7 concern GTP based S5/S8 

1. The eNodeB may send an indication of bearer release to the MME. This indication may be e.g. the Bearer 
Release Request (EPS Bearer Identity) message to the MME (e.g. the radio conditions do not allow the eNodeB 
to maintain all the allocated bearers) , or alternatively Initial Context Setup Complete, Handover Request Ack 
and UE Context Response, Path Switch Request may also indicate the release of a bearer. 

2. The MME sends the Request Dedicated Bearer Deactivation (EPS Bearer Identity) message to the Serving GW 
to deactivate the selected dedicated bearer. 

3. The Serving GW sends the Request Dedicated Bearer Deactivation (PTI, EPS Bearer Identity) message to the 
PDN GW. 

4. If PCC infrastructure is deployed, the PDN GW informs the PCRF about the loss of resources by means of a 
PCEF-initiated IP-CAN Session Modification procedure as defined in TS 23.203 [6]. The PCRF sends a updated 
PCC decision to the PDN GW. 

5. The PDN GW sends a Delete Bearer Request (PTI, EPS Bearer Identity) message to the Serving GW. 

6. Steps between 2 and 9, as described in clause 5.4.4.1, are invoked. 

7. The Serving GW deletes the bearer context related to the deactivated EPS bearer and acknowledges the bearer 
deactivation to the PDN GW by sending a Delete Bearer Response (EPS Bearer Identity) message. 
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5.4.5 UE requested bearer resource allocation 

The UE requested bearer resource allocation procedure for an E-UTRAN is depicted in figure 5.4.5-1. The procedure 
allows the UE to request for an allocation of bearer resources to one new Service Data Flow with a specific QoS 
demand. Alternatively, the procedure allows the UE to request for the modification of the GBR allocated to an active 
Service Data Flow. If accepted by the network, the request invokes either the Dedicated Bearer Activation Procedure or 
the Dedicated Bearer Modification Procedure. The procedure is used by the UE when the UE already has an IP-CAN 
session with the PDN. A UE can send a subsequent Request Bearer Resource Allocation Message before the previous 
procedure is completed. 
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Figure 5.4.5-1 : UE requested bearer resource activation 



NOTE: Steps 1, 2, and 5 are common for architecture variants with GTP-based S5/S8 and PMIP-based S5/S8. 

The procedure steps marked (A) differ in the case that PMIP-based S5/S8 is employed and is defined in 
TS 23.402 [2]. 

1. The UE sends a Request Bearer Resource Allocation (LBI, PTI, SDF QoS, TFT) message to the MME. If the UE 
was in ECM-IDLE mode, this NAS message is preceded by the Service Request procedure. The SDF QoS 
includes the QCI and, optionally, the GBR requirement of the Service Data Flow. The UE sends the Linked 
Bearer Id (LBI) to indicate to which PDN the additional bearer resource is linked to. The Procedure Transaction 
Id is dynamically allocated by the UE for UE requested bearer resource activation procedure. The UE should 
ensure as far as possible that previously used PTI values are not inmiediately reused. The PTI is released when 
the procedure is completed. 

2. The MME sends the Request Bearer Resource Allocation (IMSI, LBI, PTI, SDF QoS, TFT) message to the 
selected Serving GW. The MME validates the request using the Linked Bearer Id. The same Serving GW 
address is used by the MME as for the EPS Bearer identified by the Linked Bearer Id received in the Request 
Bearer Resource Allocation message. 

3. The Serving GW sends the Request Bearer Resource Allocation (IMSI, LBI, PTI, SDF QoS, TFT) message to 
the PDN GW. The Serving GW sends the message to the same PDN GW as for the EPS Bearer identified by the 
Linked Bearer Id. 

4. The PDN GW may either interact with PCRF to trigger the appropriate PCC decision (refer to TS 23.203 [6]), 
which may take into account subscription information, or it may apply a locally configured QoS policy. This 
corresponds to the beginning of a PCEF-initiated IP-CAN Session Modification procedure as defined in 

TS 23.203 [6], up to the point that the PDN GW requests IP-CAN Bearer Signalling. 

5. If the request is accepted, either the Dedicated Bearer Activation Procedure (according to subclause 5.4.1) or one 
of the Dedicated Bearer Modification Procedures (according to subclause 5.4.2 or 5.4.3) is invoked. The PTI 
allocated by the UE is used as a parameter in the invoked Dedicated Bearer Activation Procedure or the 
Dedicated Bearer Modification Procedure to correlate it to the UE Requested Bearer Resource Allocation 
Procedure. This provides the UE with the necessary linkage to what EPS Bearer to be used for the new SDF. The 
PDN GW shall not modify the QoS parameters requested by the UE. If the requested QoS is not granted, the 
PDN GW sends a reject indication, which shall be delivered to the UE. A cause indicates the reason why the 
request was rejected. 



ETSI 



3GPP TS 23.401 version 8.2.0 Release 8 



95 



ETSI TS 123 401 V8.2.0 (2008-10) 



6. The PDN GW indicates the result of the provisioning of poHcy during the completion of the PCEF-initiated 
IP-CAN session modification procedure as defined in TS 23.203 [6], proceding after the completion of IP-CAN 
bearer signalling. 

5.4.6 UE Requested Bearer Resource Release 

The UE Requested Bearer Resource Release procedure for an E-UTRAN is depicted in figure 5.4.6-1. The procedure 
allows the UE to request for release of bearer resources associated with a Service Data Flow. When receiving the 
request, the network invokes either the Dedicated Bearer Deactivation Procedure or the Dedicated Bearer Modification 
Procedure. 
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Figure 5.4.6-1: UE Requested Bearer Resource Release 

NOTE: Steps 1, 2, and 5 are common for architecture variants with GTP-based S5/S8 and PMIP-based S5/S8. 

The procedure steps marked (A) differ in the case that PMIP-based S5/S8 is employed and is defined in 
TS 23.402 [2]. 

1. The UE sends a Request Bearer Resource Release (LBI, PTI, TFT) message to the MME. If the UE was in 
ECM-IDLE mode, this NAS message is preceded by the Service Request procedure. The UE sends the Linked 
Bearer Id (LBI) to indicate to which PDN the bearer resource is linked to. The Procedure Transaction Id is 
dynanucally allocated by the UE for UE Requested Bearer Resource Release procedure. The UE should ensure 
as far as possible that previously used PTI values are not immediately reused. The PTI is released when the 
procedure is completed. 

2. The MME sends the Request Bearer Resource Release (IMSI, LBI, PTI, TFT) message to the Serving GW. The 
MME validates the request using the Linked Bearer Id. The same Serving GW address is used by the MME as 
for the EPS Bearer identified by the Linked Bearer Id received in the Request Bearer Resource Release message. 

3. The Serving GW sends the Request Bearer Resource Release (IMSI, LBI, PTI, TFT) message to the PDN GW. 
The Serving GW sends the message to the same PDN GW as for the EPS Bearer identified by the Linked Bearer 
Id. 



4. If PCC infrastructure is deployed, the PDN GW informs the PCRF about the change of resources. This 
corresponds to the beginning of a PCEF-initiated IP-CAN Session Modification procedure as defined in 
TS 23.203 [6], up to the point that the PDN GW requests IP-CAN Bearer Signalling. 

5. The PDN GW invokes either the Dedicated Bearer Deactivation procedure (according to subclause 5.4.4.1) or 
one of the Dedicated Bearer Modification procedures (according to clause 5.4.2 or 5.4.3). The PTI allocated by 
the UE is used as a parameter in the invoked Dedicated Bearer Deactivation or Dedicated Bearer Modification 
procedure to correlate it to the UE Requested Bearer Resource Release procedure. This provides the UE with the 
necessary linkage to which EPS Bearer the Dedicated Bearer Deactivation or Dedicated Bearer Modification 
procedure applies. 
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6. The PDN GW indicates the result of the provisioning of poHcy during the completion of the PCEF-initiated 
IP-CAN session modification procedure as defined in TS 23.203 [6], proceding after the completion of IP-CAN 
bearer signalling. 

5.5 Handover 



5.5.1 Intra-EUTRAN handover 



5.5.1 .1 Inter eNodeB handover without MME relocation 

5.5.1.1.1 General 

These procedures are used to hand over a UE from a source eNodeB to a target eNodeB when the MME is unchanged. 
Two procedures are defined depending on whether the Serving GW is unchanged or is relocated. The procedures rely 
on the presence of the X2 reference point between the source and target eNodeB, and the presence of SI -MME 
reference point between the MME and the source eNodeB as well as between the MME and the target eNodeB. The 
handover preparation and execution phases are performed as specified in TS 36.300 [5]. When the UE receives the 
handover conmiand it will remove any EPS bearers for which it did not receive and corresponding EPS radio bearers in 
the target cell. As part of handover execution, downlink packets are forwarded from the source eNodeB to the target 
eNodeB. When the UE has arrived to the target eNodeB, downlink data forwarded from the source eNodeB can be sent 
to it. Uplink data from the UE can be delivered via the (source) Serving GW to the PDN GW. Only the handover 
completion phase is affected by a potential change of the Serving GW, the handover preparation and execution phases 
are identical. 

5.5.1 .1 .2 Inter eNodeB handover without MME relocation and without Serving GW 
relocation 

This procedure is used to hand over a UE from a source eNodeB to a target eNodeB when the MME is unchanged and 
decides that the Serving GW is also unchanged. The presence of IP connectivity between the Serving GW and the 
source eNodeB, as well as between the Serving GW and the target eNodeB is assumed. 
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Figure 5.5.1 .1 .2-1 : Inter eNodeB handover without MME and without Serving GW relocation 

1. The target eNodeB sends a Path Switch Request message to MME to inform that the UE has changed cell, 
including the Cell Global Identity of the target cell and the list of rejected EPS bearers. The MME determines 
that the Serving GW can continue to serve the UE 

2. The MME sends a User Plane Update Request (eNodeB address(es) and TEIDs for downlink user plane for the 
accepted EPS bearers) message to the Serving GW. 

In case any EPS bearers are to be released the MME triggers the bearer release procedure as specified in 
clause 5.4.4.2. 

3. The Serving GW starts sending downlink packets to the target eNodeB using the newly received address and 
TEIDs. A User Plane Update Response message is sent back to the MME. 

4. In order to assist the reordering function in the target eNB, the Serving GW shall send one or more "end marker" 
packets on the old path inmiediately after switching the path for each SAE bearer of the UE as defined in 

TS 36.300 [5], clause 10.1.2.2. 

5. The MME confirms the Path Switch Request message with the Path Switch Request Ack message. The MME 
may provide the eNodeB with Handover Restriction List. Handover Restriction List is described in clause 4.3.5.7 
"Mobility Restrictions". 

6. By sending Release Resource the target eNodeB informs success of the handover to source eNodeB and triggers 
the release of resources. This step is specified in TS 36.300 [5]. 

7. Depending on RAN configuration the eNB triggers the UE to initiate a Tracking Area Update procedure. It is 
RAN functionality to provide the ECM-CONNECTED UE with the trigger information. 

NOTE: It is only a subset of the TA update procedure that is performed by the MME, since the UE is in 
ECM-CONNECTED state and the MME is not changed. 
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5.5.1.1.3 



Inter eNodeB handover without MME relocation, with Serving GW relocation 



This procedure is used to hand over a UE from a source eNodeB to a target eNodeB when the MME is unchanged and 
the MME decides that the Serving GW is to be relocated. The presence of IP connectivity between the source Serving 
GW and the source eNodeB, between the source Serving GW and the target eNodeB, and between the target Serving 
GW and target eNodeB is assumed. (If there is no IP connectivity between target eNodeB and source Serving GW, it is 
assumed that the Inter eNodeB handover with MME relocation procedure in clause 5.5.1.2 shall be used instead.) 
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Figure 5.5.1.1.3-1 : Inter eNodeB handover without MME relocation, with Serving GW relocation. 



NOTE 1: For a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. 

1. The target eNodeB sends a Path Switch Request message to MME to inform that the UE has changed cell, 
including the Cell Global Identity of the target cell and the list of rejected EPS bearers. The MME determines 
that the Serving GW is relocated and selects a new Serving GW according to clause 4.3.8.2 on "Serving GW 
Selection Function". 

NOTE 2: The MME knows the S-GW Service Area with a TA granularity. 

2. The MME sends a Create Bearer Request (bearer context(s) with PDN GW addresses and TEIDs (for GTP-based 
S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN GW(s) for uplink traffic, eNodeB address(es) and 
TEIDs for downlink user plane for the accepted EPS bearers, the Protocol Type over S5/S8) message to the 
target Serving GW. The target Serving GW allocates the S-GW addresses and TEIDs for the uplink traffic on 
S1_U reference point (one TEID per bearer). The Protocol Type over S5/S8 is provided to Serving GW which 
protocol should be used over S5/S8 interface. 

In case any EPS bearers are to be released the MME triggers the bearer release procedure as specified in 
clause 5.4.4.2. 
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3. The target Serving GW assigns addresses and TEIDs (one per bearer) for downlink traffic from the PDN GW. It 
sends an Update Bearer Request (Serving GW addresses for user plane and TEID(s)) message to the PDN 
GW(s). The PDN GW updates its context field and returns an Update Bearer Response (PDN GW address and 
TEID, MSISDN, etc.) message to the Serving GW. The MSISDN is included if the PDN GW has it stored in its 
UE context. The PDN GW starts sending downlink packets to the target GW using the newly received address 
and TEIDs. These downlink packets will use the new downlink path via the target Serving GW to the target 
eNodeB. An Update Bearer Response message is sent back to the target serving GW. 

4. The target Serving GW sends a Create Bearer Response (Serving GW addresses and uplink TEID(s) for user 
plane) message back to the target MME. The MME starts a timer, to be used in step 7. 

5. The MME confirms the Path Switch Request message with the Path Switch Request Ack (Serving GW addresses 
and uplink TEID(s) for user plane) message. The target eNodeB starts using the new Serving GW address(es) 
and TEID(s) for forwarding subsequent uplink packets. The MME may provide the eNodeB with Handover 
Restriction List. Handover Restriction List is described in clause 4.3.5.7 "Mobility Restrictions". 

6. By sending Release Resource the target eNodeB informs success of the handover to source eNodeB and triggers 
the release of resources. This step is specified in TS 36.300 [5]. 

7. When the timer has expired after step 4, the source MME releases the bearer(s) in the source Serving GW by 
sending a Delete Bearer Request message, which is acknowledged by the Serving GW. 

8. Depending on RAN configuration the eNB triggers the UE to initiate a the Tracking Area Update procedure, e.g. 
when ISR is activated. It is RAN functionality to provide the ECM-CONNECTED UE with the trigger 
information. Note that it is only a subset of the TA update procedure that is performed by the MME, since the 
UE is in ECM-CONNECTED state. During the TA update procedure the MME deactivates ISR because of the 
S-GW change. 

5.5.1 .2 Inter eNodeB handover with MME relocation 

The inter eNodeB handover with MME relocation procedure is used to relocate MME, or both the MME and the 
Serving GW. The procedure is initiated in the source eNodeB. The source MME selects the target MME. The MME 
should not be relocated during inter-eNodeB handover unless the UE leaves the MME Pool Area where the UE is 
served. If the target MME determines if the Serving GW needs to be relocated. If the Serving GW needs to be relocated 
the target MME selects the target Serving GW, as specified in clause 4.3.8.2 on Serving GW selection function. 

This procedure is also used for load re-balancing (clause 4.3.7.3), in which case the source eNodeB is identical to the 
target eNodeB. When this procedure is used for load re-balancing, a Handover Trigger message is sent from the source 
MME to the eNodeB. 

The source eNodeB decides which of the EPS bearers are subject for forwarding of packets from the source eNodeB to 
the target eNodeB. The EPC does not change the decisions taken by the RAN node. Packet forwarding can take place 
either directly from the source eNodeB to the target eNodeB, or indirectly from the source eNodeB to the target 
eNodeB via the source and target Serving GWs (or if the Serving GW is not relocated, only the single Serving GW). 

The availability of a direct forwarding path is determined in the source eNodeB and indicated to the source MME. If X2 
connectivity is available between the source and target eNodeBs, a direct forwarding path is available. 

If a direct forwarding path is not available, indirect forwarding may be used. The MMEs (source and target) use 
configuration data to determine whether indirect forwarding paths are to be established. Depending on configuration 
data, the source MME determines and indicates to the target MME whether indirect forwarding paths should be 
established. Based on this indication and on its configuration data, the target MME determines whether indirect 
forwarding paths are established. 



ETSI 



3GPP TS 23.401 version 8.2.0 Release 8 



100 



ETSI TS 123 401 V8.2.0 (2008-10) 





Source 
eNodeB 




Target 
eNodeB 


UE 







I 1 . Decisic 



10. Hando/er Commaid 



petach from old cell and 
'svnchronize t ) new cell 



DQwnlirkd^g,... 



data 



Downl i n_kJJser_P!ane 
n to trigger a relocation viaj S1 
2. Handov(?r Required ^ 



5. Handover Request 
< 



. 9. Hando^ 



/er Command 



11a. Only for Direct forwarding of dat 



12. Handolver Confirm 
-> 



Source 
MME 



5a. Handover Request A cknowledge 



6._C_reate_Be_ar^j; Request^ ^ 
ispons 

^ 7. Forwal rd Relocation Response 



.. ACceatj} Bearer_Rec|ue|t 
< aa.. Die^e^Q^^WL BaspQnse 



11_b,0nlYfc 



Uplink User Plane 
13. Handover slotify 



Target 
MME 



3. Forwa rd Relocation Request 

4. Create Bearsr Request 



Source 
Serving GW 



-4a^Create Bearer_Reseonse 



r Indirect f 



? [wardhi^ of^ da^ i_ 



data 



^_4^_Forward Relocation Complete 



14b. 



For^an 



Downlink Us er Plane cata 



17. Update Bearer Respons 



Target Serving 
GW 



ard Relocation C^omplete Ackqowledge 
5. Update Bearer Request 



PDN GW 



le.JJpdate Bear^ Request 
16r ^ 



HSS 



18. Tracking 



Area Update procedure 



19b. Delele Bearer Request 



19a. Release Resources 



19c. Delete Bearer Response 



Figure 5.5.1.2-1 : Inter-eNodeB Handover with CN Node re-location 

NOTE 1: For a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Steps 16 and 16a 
concern GTP based S5/S8. 

NOTE 2: If the Serving GW is not relocated, the box "Source Serving GW" in figure 5.5.1.2-1 is acting as the 
target Serving GW. 

1. The source eNodeB decides to initiate an inter-eNodeB handover with CN node relocation to the target eNodeB. 
This can be triggered e.g. by no X2 connectivity to the target eNodeB, or by an error indication from the target 
eNodeB after an unsuccessful X2-based handover, or by dynamic information learnt by the source eNodeB. 

If this procedure is used for load re-balancing (clause 4.3.7.3), a Handover Trigger message is sent from the 
MME to the eNodeB which triggers the next step. 
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2. The source eNodeB sends Handover Required to the source MME. The source eNodeB indicates which bearers 
are subject to data forwarding. This message contains an indication whether direct forwarding is available from 
the source eNodeB to the target eNodeB. This indication from source eNodeB can be based on e.g. the presence 
ofX2. 

3. The source MME selects the target MME as described in clause 4.3.8.3 on "MME Selection Function" and sends 
a Forward Relocation Request (MME UE context that includes the PDN GW addresses and TEIDs (for GTP- 
based S5/S8) or ORE keys (for PMIP-based S5/S8) at the PDN GW(s) for uplink traffic and Serving GW 
addresses and TEIDs for uplink traffic) message to the target MME. This message also includes an indication if 
direct forwarding is applied, or if indirect forwarding is going to be set up by the source side. 

4. The target MME verifies whether the source Serving GW can continue to serve the UE. If not, it selects a new 
Serving GW as described in clause 4.3.8.2 on "Serving GW Selection Function". 

If the source Serving GW continues to serve the UE, no message is sent in this step. In this case, the target 
Serving GW is identical to the source Serving GW. 

If a new Serving GW is selected, the target MME sends a Create Bearer Request (bearer context(s) with PDN 
GW addresses and TEIDs (for GTP-based S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN GW(s) at the 
PDN GW(s) for uplink traffic) message to the target Serving GW. The target Serving GW allocates the S-GW 
addresses and TEIDs for the uplink traffic on S1_U reference point (one TEID per bearer). The target Serving 
GW sends a Create Bearer Response (Serving GW addresses and uplink TEID(s) for user plane, the Protocol 
Type over S5/S8) message back to the target MME. The Protocol Type over S5/S8 is provided to Serving GW 
which protocol should be used over S5/S8 interface. 

5. The Target MME sends Handover Request (Serving GW addresses and uplink TEID(s) for user plane) message 
to the target eNodeB. This message creates the UE context in the target eNodeB, including information about the 
bearers, and the security context. The target eNodeB sends a Handover Request Acknowledge message to the 
target MME. This includes the the list of rejected EPS bearers and addresses and TEIDs allocated at the target 
eNodeB for downlink traffic on S1_U reference point (one TEID per bearer). It is FES if the TEIDs used for 
forwarding are different from the TEIDs used for downlink packets. 

Editor's note: TEID used for forwarding and TEID used for downlink packets is FES in RAN 

6. If indirect forwarding is used, the target MME sets up forwarding parameters in the target Serving GW. 

7. The target MME sends a Forward Relocation Response (Serving GW change indication) message to the source 
MME. In case of indirect forwarding is used this message includes Serving GW Address and TEIDs for indirect 
forwarding (source or target). Serving GW change indication indicates a new Serving GW has been selected. 

8. If indirect forwarding is used, the source MME updates the source Serving GW about the tunnels used for 
indirect forwarding. In case the Serving GW is relocated it includes the tunnel identifier to the target serving 
GW. 

9. The source MME sends a Handover Command (target addresses and TEID(s) for data forwarding) message to 
the source eNodeB. 

10. The Handover Command is sent to the UE. Upon reception of this message the UE will remove any EPS bearers 
for which it did not receive and corresponding EPS radio bearers in the target cell. 

1 1 . The source eNodeB should start forwarding of downlink data from the source eNodeB towards the target 
eNodeB for bearers subject to data forwarding. This may be either direct (step 11a) or indirect forwarding (step 
lib). 

12. After the UE has successfully synchronized to the target cell, it sends a Handover Confirm message to the target 
eNodeB. Downlink packets forwarded from the source eNodeB can be sent to the UE. Also, uplink packets can 
be sent from the UE, which are forwarded to the target Serving GW and on to the PDN GW. 

13. The target eNodeB sends a Handover Notify message to the target MME. 

14. The target MME sends a Forward Relocation Complete to the source MME. The source MME in response sends 
a Forward Relocation Complete Acknowledge to the target MME. A timer in source MME is started to supervise 
when resources in Source eNodeB and Source Serving GW shall be released. 
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15. The target MME sends an Update Bearer Request (eNodeB addresses and TEIDs allocated at the target eNodeB 
for downlink traffic on S1_U for the accepted EPS bearers, PDN GW addresses and TEIDs (for GTP-based 
S5/S8) or ORE keys (for PMIP-based S5/S8) at the PDN GW(s) for upHnk traffic) message to the target Serving 
GW. 

In case any EPS bearers are to be released the MME triggers the bearer release procedure as specified in 
clause 5.4.4.2. 

16. If the Serving GW is relocated, the target Serving GW assigns addresses and TEIDs (one per bearer) for 
downlink traffic from the PDN GW. It sends an Update Bearer Request (Serving GW addresses for user plane 
and TEID(s)) message to the PDN GW(s). The PDN GW updates its context field and returns an Update Bearer 
Response (PDN GW address and TEID, MSISDN, etc.) message to the Serving GW. The MSISDN is included if 
the PDN GW has it stored in its UE context. The PDN GW starts sending downlink packets to the target GW 
using the newly received address and TEIDs. These downlink packets will use the new downlink path via the 
target Serving GW to the target eNodeB. An Update Bearer Response message is sent back to the target serving 
GW. 

If the Serving GW is not relocated, no message is sent in this step and downlink packets from the Serving-GW 
are immediately sent on to the target eNodeB. 

It is FES if the target eNodeB needs to take any action to avoid sending DL PDUs received from the Serving- 
GW to the UE before data received from the old eNodeB have been sent to the UE. 

17. The target Serving GW sends an Update Bearer Response (PDN GW addresses and TEIDs (for GTP-based 
S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN GW(s) for upHnk traffic) message to the target MME. 

18. The eNodeB triggers the UE to initiate a Tracking Area Update procedure with the target MME. It is RAN 
functionality to provide the ECM-CONNECTED UE with the trigger information. 

Thetarget MME knows that it is a Handover procedure that has been performed for this UE as it received the 
bearer context(s) by handover messages and therefore the target MME performs only a subset of the TA update 
procedure, specifically it excludes the context transfer procedures between source MME and target MME. 

19. When the timer started in step 14 expires the source MME sends a Release Resources message to the source 
eNodeB. The source eNodeB releases its resources related to the UE. When the timer started in step 14 expires 
and if the source MME received the Serving GW change indication in the Forward Relocation Response 
message, it deletes the EPS bearer resources by sending Delete Bearer Request (Cause, TEID) messages to the 
Source Serving GW. Cause indicates to the old Serving GW that the Serving GW changes and the old Serving 
GW shall not initiate a delete procedure towards the PDN GW. The Source Serving GW acknowledges with 
Delete Bearer Response (TEID) messages. If ISR is established on the S-GW then the S-GW deletes the bearer 
resources on the other old CN node by sending Delete Bearer Request message(s) to that CN node. If resources 
for indirect forwarding have been allocated then they are released. 

5.5.2 Inter RAT handover 

Editor's note: The PDP context and EPS bearer mapping is 1-to-l for inter 3GPP RAT HOs between 2G/3G and E- 
UTRAN. Implication for an EPS bearer supporting more than 1 IP address is FES. 

Editor's note: The target SGSN or MME may restrict the received mapped QoS attributes from the source system 
during inter 3GPP RAT HOs according to its capabilities and current load. 

Editor's note: PCC interaction takes place in parallel with the bearer re-establishment in the target access in order to 
shorten the inter 3GPP RAT HO time and as changes due to PCC are assumed rare. The details of the 
PCC interaction are FES. 

5.5.2.1 E-UTRAN to UTRAN lu mode Inter RAT handover 
5.5.2.1.1 General 

Pre-conditions: 

- The UE is in ECM-CONNECTED state (E-UTRAN mode). 
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5.5.2.1.2 
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Figure 5.5.2.1.2-1 : E-UTRAN to UTRAN lu mode Inter RAT HO, preparation phase 

1. The source eNodeB decides to initiate an Inter-RAT handover to the target access network, UTRAN lu mode. At 
this point both upHnk and downUnk user data is transmitted via the following: Bearer(s) between UE and source 
eNodeB, GTP tunnel(s) between source eNodeB, Serving GW and PDN GW. 

NOTE 1 : The process leading to the handover decision is outside of the scope of this specification. 

2. The source eNodeB sends a Handover Required (Cause, Target RNC Identifier, Source eNodeB Identifier, 
Source to Target Transparent Container, Bearers Requesting Data Forwarding List) message to the source MME 
to request the CN to establish resources in the target RNC, target SGSN and the Serving GW. 

The 'Bearers Requesting Data Forwarding List' IE contains the list of bearers for which the source eNodeB 
decided that data forwarding (direct or indirect) is necessary. 

3. The source MME maps the EPS bearers to PDP contexts 1-to-l and maps the EPS QoS parameter values of an 
EPS bearer to the pre-Rel-8 QoS parameter values of a PDP context as defined in Annex E. The PDP Contexts 
shall be sent in a prioritized order, i.e. the most important PDP Context first. The prioritization method is 
implementation dependent, but should be based on the current activity. 

NOTE 2: Assigning the highest priority to the PDP context without TFT could be done to get service continuity for 
all ongoing services regardless of the number of supported EPS bearers in the UE and network. 

The source MME determines from the 'Target RNC Identifier' IE that the type of handover is IRAT Handover to 
UTRAN lu mode. The Source MME initiates the Handover resource allocation procedure by sending a Forward 
Relocation Request (IMSI, Target Identification, MM Context, PDP Context, MME Tunnel Endpoint Identifier 
for Control Plane, MME Address for Control plane. Source to Target Transparent Container, Sl-AP Cause 
Direct Forwarding Flag) message to the target SGSN. When ISR is activated the message should be sent to the 
SGSN that maintains ISR for the UE when this SGSN is serving the target identified by the Target Identification. 
This message includes all PDP contexts corresponding to the bearers established in the source system and the 
uplink Tunnel endpoint parameters of the Serving GW. 

'Direct Forwarding Flag' IE indicates if Direct Forwarding of data to Target side shall be used or not. This flag is 
set by the source MME. 

The MM context contains security related information, e.g. supported ciphering algorithms as described in 
TS 29.060 [14]. The relation between UTRAN and EPS security parameters is FES. 
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Editor's note: This needs to be aligned with security requirements for Release 8. 

Editor's note: It is FES how the mapping of individual parameters and bearer identifiers is done. It is EES how the 
bearer identifiers are mapped. 

4. The target SGSN determines if the Serving GW is relocated, e.g., due to PLMN change. If the Serving GW is 
relocated, the target SGSN selects the target Serving GW as described under clause 4.3.8.2 on "Serving GW 
selection function", and sends a Create PDP Context Request message (IMSI, SGSN Tunnel Endpoint Identifier 
for Control Plane, SGSN Address for Control plane, PDN GW address(es) for user plane, PDN GW UL TEID(s) 
for user plane, PDN GW address(es) for control plane, and PDN GW TEID(s) for control plane, the Protocol 
Type over S5/S8) to the target Serving GW. The Protocol Type over S5/S8 is provided to Serving GW which 
protocol should be used over S5/S8 interface. 

The target SGSN establishes the PDP context(s) in the indicated order. The SGSN deactivates the PDP contexts 
which cannot be established. 

4a. The target Serving GW allocates its local resources and returns a Create PDP Context Response (Serving GW 
address(es) for user plane. Serving GW UL TEID(s) for user plane. Serving GW Address for control plane. 
Serving GW TEID for control plane) message to the target SGSN. 

5. The target SGSN requests the target RNC to establish the radio network resources (RABs) by sending the 
message Relocation Request (UE Identifier, Cause, CN Domain Indicator, Integrity protection information (i.e. 
IK and allowed Integrity Protection algorithms). Encryption information (i.e. CK and allowed Ciphering 
algorithms), RAB to be setup list. Source to Target Transparent Container). 

Eor each RAB requested to be established, RABs To Be Setup shall contain information such as RAB ID, RAB 
parameters. Transport Layer Address, and lu Transport Association. The target SGSN shall not request resources 
for which the Activity Status Indicator within a PDP Context indicates that no active radio bearer exist on the 
source side for that PDP Context. The RAB ID information element contains the NSAPI value, and the RAB 
parameters information element gives the QoS profile. The Transport Layer Address is the Serving GW Address 
for user plane (in case Direct Tunnel is used) or the SGSN Address for user plane (in case Direct Tunnel is not 
used), and the lu Transport Association corresponds to the uplink Tunnel Endpoint Identifier Data in Serving 
GW or SGSN respectively. 

Ciphering and integrity protection keys are sent to the target RNC to allow data transfer to continue in the new 
RAT/mode target cell without requiring a new AKA (Authentication and Key Agreement) procedure. 
Information that is required to be sent to the UE (either in the Relocation Command message or after the 
handover completion message) from RRC in the target RNC shall be included in the RRC message sent from the 
target RNC to the UE via the transparent container. 

In the target RNC radio and lu user plane resources are reserved for the accepted RABs. 

5a. The target RNC allocates the resources and returns the applicable parameters to the target SGSN in the message 
Relocation Request Acknowledge(Target to Source Transparent Container, RABs setup list, RABs failed to 
setup list). 

Upon sending the Relocation Request Acknowledge message the target RNC shall be prepared to receive 
downlink GTP PDUs from the Serving GW, or Target SGSN in case Direct Tunnel is not used, for the accepted 
RABs. 

Each RAB to be setup is defined by a Transport Layer Address, which is the target RNC Address for user data, 
and the lu Transport Association, which corresponds to the downlink Tunnel Endpoint Identifier for user data. 

6. If 'Indirect Eorwarding' and relocation of Serving GW applies the target SGSN sends a Create PDP Context 
Request message (IMSI SGSN Tunnel Endpoint Identifier for Control Plane, SGSN Address for Control plane. 
Target RNC Address and TEID(s) for DL user plane (in case Direct Tunnel is used) or SGSN Address and 
TEID(s) for DL user plane (in case Direct Tunnel is not used)) to the target Serving GW. 

6a. The target Serving GW returns a Create PDP Context Response (Cause, Serving GW DL TEID(s)) message to 
the target SGSN. 

7. The target SGSN sends the message Eorward Relocation Response (Cause, SGSN Tunnel Endpoint Identifier for 
Control Plane, SGSN Address for Control Plane, Target to Source Transparent Container, RANAP cause, RAB 
Setup Information, Additional RAB Setup Information, Address(es) and TEID(s) for User Traffic Data 
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Forwarding, Serving GW change indication) to the source MME. Serving GW change indication indicates a new 
Serving GW has been selected. 

The IE 'Address(es) and TEID(s) for User Traffic Data Forwarding' defines the destination tunnelling endpoint 
for data forwarding in target system, and it is set as follows. 

- If 'Direct Forwarding' is applicable, then the IE 'Address(es) and TEID(s) for User Traffic Data Forwarding' 
contains the DL GTP-U tunnel endpoint parameters to the Target RNC received in Step 5a. 

- If 'Indirect Forwarding' is applicable when Direct Tunnel is used the IE 'Address(es) and TEID(s) for User 
Traffic Data Forwarding' contains the DL GTP-U tunnel endpoint parameters to the Target RNC (received in 
Step 5a) or the Target Serving GW for Serving GW re-location(received in Step 6a). 

- If 'Indirect Forwarding' is applicable when Direct Tunnel is not used the IE 'Address(es) and TEID(s) for 
User Traffic Data Forwarding' contains the DL GTP-U tunnel endpoint parameters to the Target SGSN or 
the Target Serving GW in case of Serving-GW re-location (received in Step 6a). 

8. If the "Direct Forwarding" is not applicable, the Source MME sends the message Create Bearer Request (Cause, 
Address(es) and TEID(s) for Data Forwarding (see step 7), EPS Bearer ID(s)) to the Serving GW used for 
indirect packet forwarding. The Cause indicates that the bearer(s) are subject to data forwarding. 

Indirect forwarding may be performed via a Serving GW which is different from the Serving GW used as the 
anchor point for the UE. 

8a. The Serving GW returns the forwarding parameters by sending the message Create Bearer Response (Cause, 
Serving GW Address(es) and TEID(s) for Data Forwarding). If the Serving GW doesn't support data forwarding, 
an appropriate cause value shall be returned and the Serving GW Address(es) and TEID(s) will not be included 
in the message. 
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5.5.2.1.3 



Execution phase 
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Figure 5.5.2.1.3-1: E-UTRAN to UTRAN lu mode Inter RAT HO, execution phase 

For a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Step (B) shows PCRF 
interaction in the case of PMIP-based S5/S8. Steps 8 and 8a concern GTP based S5/S8 



2. 



The source eNodeB continues to receive downlink and uplink user plane PDUs. 

The source MME completes the preparation phase towards source eNodeB by sending the message Handover 
Command (Target to Source Transparent Container, Bearers Subject to Data Forwarding List). The "Bearers 
Subject to Data forwarding list" IE may be included in the message and it shall be a list of 'Address(es) and 
TEID(s) for user traffic data forwarding' received from target side in the preparation phase (Forward Relocation 
Response message (Step 7) in case of 'Direct Forwarding', else parameters received in Step 8a). 

The source eNodeB initiates data forwarding for bearers specified in the "Bearers Subject to Data Forwarding 
List". The data forwarding may go directly to target RNC or alternatively go via the Serving GW if so decided 
by source MME and or/ target SGSN in the preparation phase. 

The source eNodeB will give a conmiand to the UE to handover to the target access network via the message HO 
from E-UTRAN Command. This message includes a transparent container including radio aspect parameters that 
the target RNC has set-up in the preparation phase. The details of this E-UTRAN specific signalling are 
described in TS 36.300 [5]. 
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Upon the reception of the HO from E-UTRAN Command message containing the Handover Command message, 
the UE shall associate its bearer IDs to the respective RABs based on the relation with the NSAPI and shall 
suspend the uplink transmission of the user plane data. 

3. The source eNodeB informs the source MME which then informs the target SGSN regarding "delivery order" 
parameters in the message Forward SRNS Context. The Target SGSN forwards the SRNS Context to the Target 
RNC. 

Editor's Note: The need for step 3 is FES. 

4. The UE moves to the target UTRAN lu (3G) system and executes the handover according to the parameters 
provided in the message delivered in step 2. The procedure is the same as in step 6 and 8 in subclause 5.2.2.2 in 
TS 43.129 [8] with the additional function of association of the received RABs and existing Bearer Id related to 
the particular NSAPI. 

The UE may resume the user data transfer only for those NSAPIs for which there are radio resources allocated in 
the target RNC. 

5. When the new source RNC-ID + S-RNTI are successfully exchanged with the UE, the target RNC shall send the 
Relocation Complete message to the target SGSN. The purpose of the Relocation Complete procedure is to 
indicate by the target RNC the completion of the relocation from the source E-UTRAN to the RNC. After the 
reception of the Relocation Complete message the target SGSN shall be prepared to receive data from the target 
RNC. Each uplink N-PDU received by the target SGSN is forwarded directly to the Serving GW. 

6. Then the target SGSN knows that the UE has arrived to the target side and target SGSN informs the source 
MME by sending the Forward Relocation Complete (ISR, Serving GW change) message. ISR indicates whether 
the target SGSN maintains ISR after the handover, which is only possible when the S-GW is not changed. The 
source MME will also acknowledge that information. A timer in source MME is started to supervise when 
resources in Source eNodeB and Source Serving GW (for Serving GW relocation) shall be released. 

When the timer expires and ISR is not indicated by the target SGSN the source MME releases all bearer 
resources of the UE. If Serving GW change is indicated and this timer expires the source MME deletes the EPS 
bearer resources by sending Delete Bearer Request (Cause, TEID) messages to the Serving GW. Cause indicates 
to the old Serving GW that the Serving GW changes and the old Serving GW shall not initiate a delete procedure 
towards the PDN GW. If Serving GW change is indicated and ISR is established on the S-GW then the S-GW 
deletes the bearer resources on the other old CN node by sending Delete Bearer Request message(s) to that CN 
node. 

7. The target SGSN will now complete the Handover procedure by informing the Serving GW (for Serving GW 
relocation this will be the Target Serving GW) that the target SGSN is now responsible for all the PDP Context 
the UE have established. This is performed in the message Update PDP Context Request (SGSN Tunnel 
Endpoint Identifier for Control Plane, NSAPI(s), SGSN Address for Control Plane, SGSN Address(es) and 
TEID(s) for User Traffic for the accepted EPS bearers (in case Direct Tunnel is not used) or RNC Address(es) 
and TEID(s) for User Traffic for the accepted EPS bearers (in case Direct Tunnel is used), PDN GW addresses 
and TEIDs (for GTP-based S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN GW(s) for uplink traffic 
and RAT type). 

In case any PDP contexts are to be released the SGSN triggers the PDP context deactivation procedure. 

8. The Serving GW (for Serving GW relocation this will be the Target Serving GW) may inform the PDN GW(s) 
the change of for example for Serving GW relocation or the RAT type that e.g. can be used for charging, by 
sending the message Update Bearer Request. The PDN GW must acknowledge the request with the message 
Update Bearer Response. In the case of Serving GW relocation, the PDN GW updates its context field and 
returns an Update Bearer Response (PDN GW address and TEID, MSISDN, etc.) message to the Serving GW. 
The MSISDN is included if the PDN GW has it stored in its UE context. 

If PCC infrastructure is used, the PDN GW informs the PCRF about the change of, for example, the RAT type. 

9. The Serving GW (for Serving GW relocation this will be the Target Serving GW) acknowledges the user plane 
switch to the target SGSN via the message Update PDP Context Response (Cause, Serving GW Tunnel Endpoint 
Identifier for Control Plane, Serving GW Address for Control Plane, Protocol Configuration Options, PDN GW 
addresses and TEIDs (for GTP-based S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN GW(s) for uplink 
traffic). At this stage the user plane path is established for all PDP contexts between the UE, target RNC, target 
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SGSN in case Direct Tunnel is not used, Serving GW (for Serving GW relocation this will be the Target Serving 
GW) and PDN GW. 

10. When the UE recognises that its current Tracking Area is not registered with the network the UE initiates a 
Routeing Area Update procedure with the target SGSN informing it that the UE is located in a new routing area. 
It is RAN functionahty to provide the PMM-CONNECTED UE with Routing Area information. 

The target SGSN knows that an IRAT Handover has been performed for this UE as it received the bearer 
context(s) by handover messages and therefore the target SGSN performs only a subset of the RAU procedure, 
specifically it excludes the context transfer procedures between source MME and target SGSN. 

1 1. When the timer started at step 6 expires, the source MME sends a Release Resources message to the Source 
eNodeB. The Source eNodeB releases its resources related to the UE. 

When the timer started in step 6 expires and if the source MME received the Serving GW change indication in 
the Forward Relocation Response message, it deletes the EPS bearer resources by sending Delete Bearer Request 
(Cause, TEID) messages to the Source Serving GW. Cause indicates to the old Serving GW that the old Serving 
GW shall not initiate a delete procedure towards the PDN GW. The Source Serving GW acknowledges with 
Delete Bearer Response (TEID) messages. If ISR is established on the S-GW then the S-GW deletes the bearer 
resources on the other old CN node by sending Delete Bearer Request message(s) to that CN node. If resources 
for indirect forwarding have been allocated then they are released. 



5.5.2.2 



UTRAN lu mode to E-UTRAN Inter RAT handover 



5.5.2.2.1 



General 



The UTRAN lu mode to E-UTRAN Inter RAT handover procedure takes place when the network decides to perform a 
handover. The decision to perform PS handover from UTRAN lu mode to E-UTRAN is taken by the network based on 
radio condition measurements reported by the UE to the UTRAN RNC. 
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Figure 5.5.2.2.2-1 : UTRAN lu mode to E-UTRAN Inter RAT HO, preparation phase 

1 . The source RNC decides to initiate an Inter-RAT handover to the E-UTRAN. At this point both uplink and 
downlink user data is transmitted via the following: Bearers between UE and source RNC, GTP tunnel(s) 
between source RNC, source SGSN (only in case Direct Tunnel is not used). Serving GW and PDN GW. 
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NOTE 1 : The process leading to the handover decision is outside of the scope of this specification. 

2. The source RNC sends a Relocation Required (Cause, Target eNodeB Identifier, Source RNC Identifier, Source 
to Target Transparent Container, Bearers Requesting Data Forwarding List) message to the source SGSN to 
request the CN to establish resources in the target eNodeB, Target MME and the Serving GW. The 'Bearers 
Requesting Data Forwarding List' IE contains that list of RABs for which the source RNC decided that data 
forwarding (direct or indirect) is necessary. 

3. The source SGSN determines from the 'Target eNodeB Identifier' IE that the type of handover is IRAT 
Handover to E-UTRAN. The Source SGSN initiates the Handover resource allocation procedure by sending 
Forward Relocation Request (IMSI, Target Identification, MM Context, PDP Context, SGSN Tunnel Endpoint 
Identifier for Control Plane, SGSN Address for Control plane. Source to Target Transparent Container, Direct 
Forwarding Flag) message to the target MME. This message includes all PDP contexts corresponding to all the 
bearers established in the source system and the uplink Tunnel endpoint parameters of the Serving GW. When 
ISR is activated the message should be sent to the MME that maintains ISR for the UE when this MME is 
serving the target identified by the Target Identification. 

The PDP Contexts shall be sent in a prioritized order, i.e. the most important PDP Context first. The 
prioritization method is implementation dependent, but should be based on the current activity. 

NOTE 2: Assigning the highest priority to the PDP context without TFT could be done to get service continuity for 
all ongoing services regardless of the number of supported EPS bearers in the UE and network. 

The 'Direct Forwarding Flag' IE indicates if Direct Forwarding of data to the target side shall be used or not. This 
flag is set by the source SGSN. 

The MM context contains security related information, e.g. UE capabilities and used NAS integrity and 
ciphering algorithm(s) as well as keys, as described in TS 29.060 [14]. 

The target MME selects the ciphering algorithm to use. This algorithm will be sent transparently from the target 
eNodeB to the UE in the Target to Source Transparent Container (EPC part). 

The target MME maps the PDP contexts to the EPS bearers 1-to-l and maps the pre-Rel-8 QoS parameter values 
of a PDP context to the EPS QoS parameter values of an EPS bearer as defined in Annex E. The MME 
establishes the EPS bearer(s) in the indicated order. The MME deactivates the EPS bearers which cannot be 
established. 

Editor's note: This needs to be aligned with security requirements for Release 8. 

Editor's note: It is FES how the mapping of individual parameters and bearer identifiers is done. It is FES how the 
bearer identifiers are mapped. 

4. The target MME determines if the Serving GW is relocated, e.g., due to PLMN change. If the Serving GW is 
relocated, the target MME selects the target Serving GW as described under clause 4.3.8.2 on "Serving GW 
selection function". The target MME sends a Create Bearer Request message (IMSI, MME context ID, MME 
Tunnel Endpoint Identifier for Control Plane, MME Address for Control plane, PDN GW address(es) for user 
plane, PDN GW UL TEID(s) for user plane, PDN GW address for control plane, and PDN GW TEID(s) for 
control plane, the Protocol Type over S5/S8) to the target Serving GW. The Protocol Type over S5/S8 is 
provided to Serving GW which protocol should be used over S5/S8 interface. 

4a. The target Serving GW allocates its local resources and returns them in a Create Bearer Response (Serving GW 
address(es) for user plane. Serving GW UL TEID(s) for user plane. Serving GW Address for control plane. 
Serving GW TEID for control plane) message to the target MME. 

5. The target MME requests the target eNodeB to establish the bearer(s) by sending the message Handover Request 
(UE Identifier, Cause, KeNB, allowed AS Integrity Protection and Ciphering algorithm(s), NAS Integrity 
Protection and Ciphering algorithm(s), EPS Bearers to be setup list. Source to Target Transparent Container). 
NAS Integrity Protection and Ciphering algorithm(s), KSI and key derivation parameters are targeted for the UE. 

If the MME already has a security association with the UE, the earlier selected NAS Integrity Protection and 
Ciphering algorithm(s) and keys are indicated. If the MME does not have a security association with the UE, 
then NAS Integrity Protection and Ciphering algorithm(s) are selected utilizing information of the MM context 
about supported algorithms. 
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Editor's Note: It is for further study if the KSI parameter informs the UE whether a security association exists with 
the MME and is used or whether it does not exist and UTRAN CK and IK based keys are used in target 
eNodeB and in the target MME. 

For each EPS bearer requested to be estabhshed, 'EPS Bearers To Be Setup' IE shall contain information such as 
ID, bearer parameters, Transport Layer Address, and SI Transport Association. The target MME shall not 
request resources for which the Activity Status Indicator within a PDP Context indicates that no active radio 
bearer exist on the source side for that PDP context. The Transport Layer Address is the Serving GW Address 
for user data, and the S 1 Transport Association corresponds to the uplink Tunnel Endpoint Identifier Data. 

The information about the selected ciphering and integrity protection algorithm(s), KSI and key derivation 
parameter will be sent transparently from the target eNodeB to the UE in the Target to Source Transparent 
Container, and in the message UTRAN HO Command from source RNC to the UE. This will then allow data 
transfer to continue in the new RAT/mode target cell without requiring a new AKA (Authentication and Key 
Agreement) procedure. 

5 a. The target eNodeB allocates the request resources and returns the applicable parameters to the target MME in the 
message Handover Request Acknowledge (Target to Source Transparent Container, EPS Bearers setup list, EPS 
Bearers failed to setup list). Upon sending the Handover Request Acknowledge message the target eNodeB shall 
be prepared to receive downlink GTP PDUs from the Serving GW for the accepted EPS bearers. 

6. If 'Indirect Forwarding' and relocation of Serving GW applies the target MME sends an Create Bearer Request 
message (IMSI, MME TEID for control plane, MME Address for control plane,. Target eNodeB Address, 
TEID(s) for DL user plane) to the target Serving GW. 

The target eNodeB selects AS integrity and ciphering algorithm(s). In addition to the information provided by 
the MME (KSI, NAS Integrity Protection and Ciphering algorithm(s) and key derivation parameter), the target 
eNodeB inserts AS integrity and ciphering algorithm(s) and eNodeB C-RNTI into the UTRAN RRC message, 
which is contained in the Target to Source Transparent Container. The eNodeB C-RNTI is used by the UE to 
derive target eNodeB KeNB as well as the RRC and UP keys. 

Editor's Note: The usage of the C-RNTI is under discussion in SA3 and therefore FES. 

6a. The target Serving GW returns a Create Bearer Response (Cause, Serving GW DL TEID(s)) message to the 
target MME. 

7. The target MME sends the message Forward Relocation Response (Cause, List of Set Up RABs, MME Tunnel 
Endpoint Identifier for Control Plane, Sl-AP cause, MME Address for control plane. Target to Source 
Transparent Container, Address(es) and TEID(s) for Data Forwarding, Serving GW change indication) to the 
source SGSN. Serving GW change indication indicates a new Serving GW has been selected. 

The IE 'Address(es) and TEID(s) for User Traffic Data Forwarding' defines the destination tunnelling endpoint 
for data forwarding in target system, and it is set as follows. If 'Direct Forwarding' is applicable, then the lEs 
'Address(es) and TEID(s) for Data Forwarding' contains the DL GTP-U tunnel endpoint parameters to the 
eNodeB. 

If 'Indirect Forwarding' is applicable the lEs 'Address(es) and TEID(s) for Data Forwarding' contains the DL 
GTP-U tunnel endpoint parameters to the Target eNodeB or to the Target Serving GW for Serving GW re- 
location. 

8. If "Direct Forwarding" is not applicable, the source SGSN shall send the message Create Bearer Request (Cause, 
Address(es) and TEID(s) for Data Forwarding (see step 7), NSAPI(s)) to the Serving GW used for indirect 
packet forwarding. The Cause shall indicate that the Bearer is subject to data forwarding. 

Indirect forwarding may be performed via a Serving GW which is different from the Serving GW used as the 
anchor point for the UE. 

8a. The Serving GW returns the forwarding user plane parameters by sending the message Create Bearer Response 
(Cause, Serving GW Address(es) and TEID(s) for Data Forwarding). If the Serving GW doesn't support data 
forwarding, an appropriate cause value shall be returned and the Serving GW Address(es) and TEID(s) will not 
be included in the message. 
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5.5.2.2.3 
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Figure 5.5.2.2.3-1 : UTRAN lu mode to E-UTRAN Inter RAT HO, execution phase 



NOTE: For a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Step (B) shows PCRF 
interaction in the case of PMIP-based S5/S8. Steps 9 and 9a concern GTP based S5/S8. 

The source RNC continues to receive downUnk and upHnk user plane PDUs. 

1. The source SGSN completes the preparation phase towards source RNC by sending the message Relocation 
Command (Target to Source Transparent Container, RABs to be Released List, RABs Subject to Data 
Forwarding List). The "RABs to be Released Hst" IE will be the Hst of all NSAPIs (RAB Ids) for which a Bearer 
was not established in Target eNodeB. The "RABs Subject to Data forwarding list" IE may be included in the 
message and it shall be a list of 'Address(es) and TEID(s) for user traffic data forwarding' received from target 
side in the preparation phase (Forward Relocation Response message (Step 7) in case of 'Direct Forwarding' is 
applicable. In case 'Indirect Forwarding' is applicable and Direct Tunnel is not used the "RABs Subject to Data 
Forwarding" IE includes the source SGSN address(es) and TEID(s) allocated for indirect data forwarding by 
Source SGSN. In case 'Indirect Forwarding' is applicable and Direct Tunnel is used the "RABs Subject to Data 
Forwarding" IE includes paramters received in Step 8a). 

2. The source RNC will command to the UE to handover to the target eNodeB via the message HO from UTRAN 
Command. The access network specific message to UE includes a transparent container including radio aspect 
parameters that the target eNodeB has set-up in the preparation phase. The procedures for this are FES. 

The source RNC may initiate data forwarding for the indicated RABs/PDP contexts specified in the "RABs 
Subject to Data Forwarding List". The data forwarding may go directly to target eNodeB, or alternatively go e.g. 
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via the source SGSN (in case Direct Tunnel is not used) and the Serving GW if so decided by source SGSN 
and/or target MME in the preparation phase. 

Upon the reception of the HO from UTRAN Command message containing the Relocation Command message, 
the UE shall associate its RAB IDs to the respective bearers ID based on the relation with the NSAPI and shall 
suspend the uplink transmission of the user plane data. 

3. The Source RNC may inform the Source SGSN which then informs the Target MME regarding "delivery order" 
parameters in the message Forward SRNS Context. 

The target MME forwards the SRNS Context to eNodeB. 

The need for the step 3 is FFS. 

4. The UE moves to the E-UTRAN and performs access procedures toward target eNodeB. 

5. When the UE has got access to target eNodeB it sends the message HO to E-UTRAN Complete. 

6. When the UE has successfully accessed the target eNodeB, the target eNodeB informs the target MME by 
sending the message Handover Notify. 

7. Then the target MME knows that the UE has arrived to the target side and target MME informs the source SGSN 
by sending the Forward Relocation Complete (ISR, Serving GW change) message. ISR indicates whether the 
target MME maintains ISR after the handover, which is only possible when the S-GW is not changed. The 
source SGSN will also acknowledge that information. A timer in source SGSN is started to supervise when 
resources in the in Source RNC and Source Serving GW (in case of Serving GW relocation) shall be released 

8. The target MME will now complete the Inter-RAT Handover procedure by informing the Serving GW (for 
Serving GW relocation this will be the Target Serving GW) that the target MME is now responsible for all the 
bearers the UE have established. This is performed in the message Update Bearer Request (Cause, MME Tunnel 
Endpoint Identifier for Control Plane, EPS Bearer ID, MME Address for Control Plane, eNodeB Address(es) 
and TEID(s) for User Traffic for the accepted EPS bearers, PDN GW addresses and TEIDs (for GTP-based 
S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN GW(s) for uplink traffic and RAT type). 

In case any EPS bearers are to be released the MME triggers the bearer release procedure as specified in 
clause 5.4.4.2. 

9. The Serving GW (for Serving GW relocation this will be the Target Serving GW) may inform the PDN GW the 
change of for example for Serving GW relocation or the RAT type that e.g. can be used for charging, by sending 
the message Update Bearer Request. The PDN GW must acknowledge the request with the message Update 
Bearer Response. In the case of Serving GW relocation, the PDN GW updates its context field and returns an 
Update Bearer Response (PDN GW address and TEID, MSISDN, etc.) message to the Serving GW. The 
MSISDN is included if the PDN GW has it stored in its UE context. 

If PCC infrastructure is used, the PDN GW informs the PCRF about the change of, for example, the RAT type. 

10. The Serving GW (for Serving GW relocation this will be the Target Serving GW) acknowledges the user plane 
switch to the target MME via the message Update Bearer Response (Cause, Serving GW Tunnel Endpoint 
Identifier for Control Plane, Serving GW Address for Control Plane, Protocol Configuration Options, PDN GW 
addresses and TEIDs (for GTP-based S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN GW(s) for uplink 
traffic). At this stage the user plane path is established for all bearers between the UE, target eNodeB, Serving 
GW (for Serving GW relocation this will be the Target Serving GW) and PDN GW. 

1 1 . The eNodeB triggers the UE to initiate a Tracking Area Update procedure with the target MME informing it that 
the UE is located in a new tracking area. It is RAN functionality to provide the ECM-CONNECTED UE with 
the trigger information. 

The target MME knows that an IRAT Handover has been performed for this UE as it received the bearer 
context(s) by handover messages and therefore the target MME performs only a subset of the TA update 
procedure, specifically it excludes the context transfer procedures between source SGSN and target MME. 

12. When the timer started in step 7 expires the source SGSN will clean-up all its resources towards source RNC by 
performing the lu Release procedures. When there is no longer any need for the RNC to forward data, the source 
RNC responds with an lu Release Complete message. 
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When the timer started in step 7 expires and if the source SGSN received the Serving GW change indication in 
the Forward Relocation Response message, it deletes the EPS bearer resources by sending Delete Bearer Request 
(Cause, TEID) messages to the Source Serving GW. Cause indicates to the old Serving GW that the Serving GW 
changes and the old Serving GW shall not initiate a delete procedure towards the PDN GW. The Source Serving 
GW acknowledges with Delete Bearer Response (TEID) messages. If ISR is established on the S-GW then the 
S-GW deletes the bearer resources on the other old CN node by sending Delete Bearer Request message(s) to 
that CN node. If resources for indirect forwarding have been allocated then they are released. 



5.5.2.3 



E-UTRAN to GERAN A/Gb mode Inter RAT handover 



5.5.2.3.1 General 

The procedure is based on Packet-switched handover for GERAN A/Gb mode defined in TS 43.129 [8]. 
Pre-conditions: 

- The UE is in ECM-CONNECTED state (E-UTRAN mode); 

- The BSS must support PFM, Packet Flow Management, procedures. 



5.5.2.3.2 
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Figure 5.5.2.3.2-1: E-UTRAN to GERAN A/Gb Inter RAT HO, preparation phase 

1 . The source eNodeB decides to initiate an Inter RAT Handover to the target GERAN A/Gb mode (2G) system. At 
this point both uphnk and downhnk user data is transnutted via the following: Bearer(s) between UE and Source 
eNodeB, GTP tunnel(s) between Source eNodeB, Serving GW and PDN GW. 

NOTE 1: The process leading to the handover decision is outside of the scope of this specification 

2. The source eNodeB sends a Handover Required (Cause, Target System Identifier, Source eNodeB Identifier, 
Source to Target Transparent Container, Bearers Requesting Data Forwarding List) message to the Source MME 
to request the CN to establish resources in the Target BSS, Target SGSN and the Serving GW. 

The 'Target System Identifier' IE contains the identity of the target global cell Id. 

The 'Bearers Requesting Data Forwarding List' IE contains the list of bearers for which the source eNodeB 
decided that data forwarding (direct or indirect) is necessary. 
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3. The source MME maps the EPS bearers to PDP contexts 1-to-l and maps the EPS QoS parameter values of an 
EPS bearer to the pre-Rel-8 QoS parameter values of a PDP context as defined in Annex E. The PDP Contexts 
shall be sent in a prioritized order, i.e. the most important PDP Context first. The prioritization method is 
implementation dependent, but should be based on the current activity. 

NOTE 2: Assigning the highest priority to the PDP context without TFT could be done to get service continuity for 
all ongoing services regardless of the number of supported EPS bearers in the UE and network. 

The Source MME determines from the Target System Identifier' IE that the type of handover is IRAT Handover 
to GERAN A/Gb mode. The Source MME initiates the Handover resource allocation procedure by sending a 
Forward Relocation Request (IMSI, Target Identification (shall be set to "empty"), MM Context, PDP Context, 
MME Tunnel Endpoint Identifier for Control Plane, MME Address for Control plane. Source to Target 
Transparent Container, Packet Flow ID , XID parameters (if available). Target Cell Identification, Direct 
Forwarding Flag) message to the target SGSN. When ISR is activated the message should be sent to the SGSN 
that maintains ISR for the UE when this SGSN is serving the target identified by the Target Identification. This 
message includes all PDP contexts corresponding to the bearers established in the source system and the uplink 
Tunnel endpoint parameters of the Serving GW. If the Source MME supports IRAT Handover to GERAN A/Gb 
procedure it has to allocate a valid PFI during the bearer activation procedure. 

The 'Direct Forwarding Flag' IE indicates if Direct Forwarding of data to Target side shall be used or not. This 
flag is set by the source MME. 

The MM context contains security related information, e.g. supported ciphering algorithms, as described in 
TS 29.060 [14]. The relation between GSM and EPS security parameters is FES. 

The target SGSN selects the ciphering algorithm to use. This algorithm will be sent transparently from the target 
SGSN to the UE in the NAS container for Handover (part of the Target to Source Transparent Container). The 
lOV-UI parameter, generated in the target SGSN, is used as input to the ciphering procedure and it will also be 
transferred transparently from the target SGSN to the UE in the NAS container for Handover. 

Editor's note: This needs to be aligned with security requirements for Release 8. 

Editor's note: It is FES how the mapping of individual parameters and bearer identifiers is done. It is FES how the 
bearer identifiers are mapped. 

When the target SGSN receives the Forward Relocation Request message the required PDP, MM, SNDCP and 
LLC contexts are established and a new P-TMSI is allocated for the UE. When this message is received by the 
target SGSN, it begins the process of establishing PFCs for all PDP contexts. 

When the target SGSN receives the Forward Relocation Request message it extracts from the PDP Contexts the 
NSAPIs and SAPIs and PFIs to be used in the target SGSN. If for a given PDP Context the target SGSN does 
not receive a PFI from the source MME, it shall not request the target BSS to allocate TBF resources 
corresponding to that PDP Context. If none of the PDP Contexts forwarded from the source MME has a valid 
PFI allocated the target SGSN shall consider this as a failure case and the request for Handover shall be rejected. 

If when an SAPI and PFI was available at the source MME but the target SGSN does not support the same SAPI 
and PFI for a certain NSAPI as the source MME, the target SGSN shall continue the Handover procedure only 
for those NSAPIs for which it can support the same PFI and SAPI as the source MME. All PDP contexts for 
which no resources are allocated by the target SGSN or for which it cannot support the same SAPI and PFI (i.e. 
the corresponding NSAPIs are not addressed in the response message of the target SGSN), are maintained and 
the related SAPIs and PFIs are kept. These PDP contexts may be modified or deactivated by the target SGSN via 
explicit SM procedures upon RAU procedure. 

The source MME shall indicate the current XID parameter settings if available (i.e. those XID parameters 
received during a previous IRAT Handover procedure) to the target SGSN. If the target SGSN can accept all 
XID parameters as indicated by the source MME, the target SGSN shall create a NAS container for Handover 
indicating 'Reset to the old XID parameters'. Otherwise, if the target SGSN cannot accept all XID parameters 
indicated by the source MME or if no XID parameters were indicated by the source MME, the target SGSN shall 
create a NAS container for Handover indicating Reset (i.e. reset to default parameters). 

4. The target SGSN determines if the Serving GW is relocated, e.g., due to PLMN change. If the Serving GW is 
relocated, the target SGSN selects the target Serving GW as described under clause 4.3.8.2 on "Serving GW 
selection function", and sends a Create PDP Context Request message (IMSI, SGSN Tunnel Endpoint Identifier 
for Control Plane, SGSN Address for Control plane, PDN GW address(es) for user plane, PDN GW UL TEID(s) 
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for user plane, PDN GW address(es) for control plane, and PDN GW TEID(s) for control plane, the Protocol 
Type over S5/S8) to the target Serving GW. The Protocol Type over S5/S8 is provided to Serving GW which 
protocol should be used over S5/S8 interface. 

4a. The target Serving GW allocates its local resources and returns a Create PDP Context Response (Serving GW 
address(es) for user plane. Serving GW UL TEID(s) for user plane, Serving GW Address for control plane, 
Serving GW TEID for control plane) message to the target SGSN. 

5. The target SGSN establishes the PDP context(s) in the indicated order. The SGSN deactivates the PDP contexts 
which cannot be established. 

The Target SGSN requests the Target BSS to establish the necessary resources (PFCs) by sending the message 
PS Handover Request (Local TLLI, IMSI, Cause, Target Cell Identifier, PFCs to be set-up list. Source to Target 
Transparent Container and NAS container for handover). The target SGSN shall not request resources for which 
the Activity Status Indicator within a PDP Context indicates that no active bearer exists on the source side for 
that PDP context. 

Based upon the ABQP for each PFC the target BSS makes a decision about which PFCs to assign radio 
resources. The algorithm by which the BSS decides which PFCs that need resources is implementation specific. 
Due to resource limitations not all downloaded PFCs will necessarily receive resource allocation. The target BSS 
allocates TBFs for each PFC that it can accommodate. 

The target BSS shall prepare the 'Target to Source Transparent Container' which contains a PS Handover 
Conmiand including the EPC part (NAS container for Handover) and the RN part (Handover Radio Resources). 

5a. The Target BSS allocates the requested resources and returns the applicable parameters to the Target SGSN in 
the message PS Handover Request Acknowledge (Local TLLI, List of set-up PFCs, Target to Source 
Transparent Container). Upon sending the PS Handover Request Acknowledge message the target BSS shall be 
prepared to receive downlink LLC PDUs from the target SGSN for the accepted PFCs. 

Any PDP contexts for which a PFC was not established are maintained in the target SGSN and the related SAPIs 
and PFIs are kept. These PDP contexts may be modified or deactivated by the target SGSN via explicit SM 
procedures upon the completion of the routing area update (RAU) procedure. 

6. If indirect forwarding and relocation of Serving GW applies the target SGSN sends a Create PDP Context 
Request message (IMSI, SGSN Tunnel Endpoint Identifier for Control Plane, SGSN Address for Control plane. 
Target SGSN Address(es) and TEID(s) for DL user plane) to the target Serving GW. 

6a. The target Serving GW returns a Create PDP Context Response (Cause, Serving GW DL TEID(s)) message to 
the target SGSN. 

7. The Target SGSN sends the message Forward Relocation Response (Cause, SGSN Tunnel Endpoint Identifier 
for Control Plane, SGSN Address for Control Plane, Target to Source Transparent Container (in the 'BSS 
Container' IE), BSSGP Cause, List of set-up PFIs, Address(es) and TEID(s) for User Traffic Data Forwarding, 
Serving GW change indication) to the Source MME. Serving GW change indication indicates a new Serving 
GW has been selected. 

If 'Direct Forwarding' is applicable, then the lEs 'Address(es) and TEID(s) for User Traffic Data Forwarding' 
contains the DL GTP-U tunnel endpoint parameters to the Target SGSN. Otherwise the lEs 'Address(es) and 
TEID(s) for User Traffic Data Forwarding' contains the DL GTP-U tunnel endpoint parameters to the Target 
SGSN or to the Target Serving GW in case of Serving GW re-location. 

The target SGSN activates the allocated LLC/SNDCP engines as specified in TS 44.064 [23] for an SGSN 
originated Reset or 'Reset to the old XID parameters'. 

8. If "Direct Forwarding" is not applicable, the Source MME sends the message Create Bearer Request (Cause, 
Address(es) and TEID(s) for Data Forwarding (see step 7), NSAPI(s)) to the Serving GW used for indirect 
packet forwarding. The Cause indicates that the bearer(s) are subject to data forwarding. 

Indirect forwarding may be performed via a Serving GW which is different from the Serving GW used as the 
anchor point for the UE. 

8a. The Serving GW returns the forwarding user plane parameters by sending the message Create Bearer Response 
(Cause, Serving GW Address(es) and TEID(s) for Data Forwarding). If the Serving GW doesn't support data 
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forwarding, an appropriate cause value shall be returned and the Serving GW Address(es) and TEID(s) will not 
be included in the message. 
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Figure 5.5.2.3.3-1 : E-UTRAN to GERAN A/Gb mode Inter RAT HO, execution phase 



NOTE 1: For a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Step (B) shows PCRF 
interaction in the case of PMIP-based S5/S8. Steps 10 and 10a concern GTP based S5/S8 

The source eNodeB continues to receive downlink and uplinkuser plane PDUs. 

1. The Source MME completes the preparation phase towards Source eNodeB by sending the message Handover 
Command (Target to Source Transparent Container (PS Handover Conmiand with RN part and EPC part), 
Bearers Subject to Data Forwarding List). The "Bearers Subject to Data forwarding list" may be included in the 
message and it shall be a list of 'Address(es) and TEID(s) for user traffic data forwarding' received from target 
side in the preparation phase (Forward Relocation Response message (Step 7) in case of Direct Forwarding, else 
parameters received in Step 8a). 
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Source eNodeB initiate data forwarding for the bearers specified in the "Bearers Subject to Data Forwarding 
List". The data forwarding may go directly i.e. to target SGSN or alternatively go via the Serving GW if so 
decided by source MME and/or target SGSN in the preparation phase. 

2. The Source eNodeB will give a command to the UE to handover to the Target Access System via the message 
HO from E-UTRAN Command. This message includes a transparent container including radio aspect parameters 
that the Target BSS has set-up in the preparation phase (RN part). This message also includes the XID and lOV- 
UI parameters received from the Target SGSN (EPC part). 

Upon the reception of the HO from E-UTRAN Command message containing the Handover Command message, 
the UE shall associate its bearer IDs to the respective PFIs based on the relation with the NSAPI and shall 
suspend the uplink transmission of the user plane data. 

3. The Source eNodeB may inform the Source MME which then informs the Target SGSN regarding "delivery 
order" parameters in the message Forward SRNS Context. 

The need for step 3 is FFS. 

4. The UE moves to the Target GERAN A/Gb (2G) system and performs executes the handover according to the 
parameters provided in the message delivered in step 2. The procedure is the same as in step 6 in subclause 
5.3.2.2 in TS 43.129 [8] with the additional function of association of the received PFI and existing Bearer Id 
related to the particular NSAPI. 

5. After accessing the cell using access bursts and receiving timing advance information from the BSS in step 4, the 
UE processes the NAS container and then sends one XID response message to the target SGSN via target BSS. 
The UE sends this message immediately after receiving the Packet Physical Information message containing the 
timing advance or, in the synchronised network case, immediately if the PS Handover Access message is not 
required to be sent. 

Upon sending the XID Response message, the UE shall resume the user data transfer only for those NSAPIs for 
which there are radio resources allocated in the target cell. For NSAPIs using LLC ADM, for which radio 
resources were not allocated in the target cell, the MS may request for radio resources using the legacy 
procedures. 

If the Target SGSN indicated XID Reset (i.e. reset to default XID parameters) in the NAS container included in 
the HO from E-UTRAN Command message, and to avoid collision cases the mobile station may avoid triggering 
XID negotiation for any LLC SAPI used in LLC ADM, but wait for the SGSN to do so (see step 12). In any case 
the mobile station may avoid triggering XID negotiation for any LLC SAPI used in LLC ABM, but wait for the 
SGSN to do so (see step 12a). 

This step is the same as specified in clause 5.3.2.2 in TS 43.129 [8]. 

6. Upon reception of the first correct RLC/MAC block (sent in normal burst format) from the UE to the Target 
BSS, the Target BSS informs the Target SGSN by sending the message PS Handover Complete (IMSI, and 
Local TLLI). 

7. The Target BSS also relays the message XID Response to the Target SGSN. Note, the message in step 6 and 7 
may arrive in any order in the Target SGSN. 

8. Then the Target SGSN knows that the UE has arrived to the target side and Target SGSN informs the Source 
MME by sending the Forward Relocation Complete (ISR, Serving GW change) message. ISR indicates whether 
the target SGSN maintains ISR after the handover, which is only possible when the S-GW is not changed. The 
Source MME will also acknowledge that information. A timer in source MME is started to supervise when 
resources in Source eNodeB and Source Serving GW (in case of Serving GW relocation) shall be released. 

9. The Target SGSN will now complete the Handover procedure by informing the Serving GW (for Serving GW 
relocation this will be the Target Serving GW) that the Target SGSN is now responsible for all the PDP Context 
the UE have established. This is performed in the message Update PDP Context Request (Serving GW Tunnel 
Endpoint Identifier for Control Plane, NSAPI(s), SGSN Address for Control Plane, SGSN Address(es) and 
TEID(s) for User Traffic for the accepted EPS bearers, PDN GW addresses and TEIDs (for GTP-based S5/S8) or 
GRE keys (for PMIP-based S5/S8) at the PDN GW(s) for uplink traffic and RAT type). 

In case any PDP contexts are to be released the SGSN triggers the PDP context deactivation procedure. 
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10. The Serving GW (for Serving GW relocation this will be the Target Serving GW) may inform the PDN GW the 
change of, for example, in case of Serving GW relocation or the RAT type, that e.g. can be used for charging, by 
sending the message Update Bearer Request. The PDN GW must acknowledge the request with the message 
Update Bearer Response. In the case of Serving GW relocation, the PDN GW updates its context field and 
returns an Update Bearer Response (PDN GW address and TEID, MSISDN, etc.) message to the Serving GW. 
The MSISDN is included if the PDN GW has it stored in its UE context. 

If PCC infrastructure is used, the PDN GW informs the PCRF about the change of, for example, the RAT type. 

1 1. The Serving GW (for Serving GW relocation this will be the Target Serving GW) acknowledges the user plane 
switch to the Target SGSN via the message Update PDP Context Response (Cause, Serving GW Tunnel 
Endpoint Identifier for Control Plane, Serving GW Address for Control Plane, Protocol Configuration Options, 
PDN GW addresses and TEIDs (for GTP-based S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN GW(s) 
for uplink traffic). At this stage the user plane path is established for all PDP contexts between the UE, Target 
BSS, Target SGSN, Serving GW (for Serving GW relocation this will be the Target Serving GW) and PDN GW. 

12. If the Target SGSN indicated XID Reset (i.e. reset to default XID parameters) in the NAS container included in 
the HO from E-UTRAN Command message, then on receipt of the PS Handover Complete the Target SGSN 
initiates an LLC/SNDCP XID negotiation for each LLC SAPI used in LLC ADM. In this case if the Target 
SGSN wants to use the default XID parameters, it shall send an empty XID Conmiand. If the Target SGSN 
indicated 'Reset to the old XID parameters' in the NAS container, no further XID negotiation is required for LLC 
SAPIs used in LLC ADM only. 

12a. The Target SGSN (re-)establishes LLC ABM for the PDP contexts which use acknowledged information 
transfer. During the exchange of SABM and UA the SGSN shall perform LLC/SNDCP XID negotiation. 

These steps (12 and 12a) are the same as specified in clause 5.3.2.2 in TS 43.129 [8]. 

13. The RAN triggers the UE to initiate a Routeing Area Update procedure with the target SGSN. It is RAN 
functionality to provide the PMM-CONNECTED UE with the trigger information. 

The target SGSN knows that an IRAT Handover has been performed for this UE as it received the bearer 
context(s) by handover messages and therefore the target SGSN performs only a subset of the RAU procedure, 
specifically it excludes the context transfer procedures between source MME and target SGSN. 

14. When the timer started at step 8 expires, the source MME sends a Release Resources message to the source 
eNodeB. The Source eNodeB releases its resources related to the UE. 

When the timer started in step 8 expires and if the source MME received the Serving GW change indication in the 
Forward Relocation Response message, it deletes the EPS bearer resources by sending Delete Bearer Request 
(Cause, TEID) messages to the Source Serving GW. Cause indicates to the old Serving GW that the Serving GW 
changes and the old Serving GW shall not initiate a delete procedure towards the PDN GW. The Source Serving 
GW acknowledges with Delete Bearer Response (TEID) messages. If ISR is established on the S-GW then the 
S-GW deletes the bearer resources on the other old CN node by sending Delete Bearer Request message(s) to 
that CN node. If resources for indirect forwarding have been allocated then they are released. 



The procedure is based on Packet-switched handover for GERAN A/Gb mode, defined in TS 43.129 [8]. 
Pre-conditions: 

- The UE is in READY state (GERAN A/Gb mode); 

- The UE has at least one PDP Context established; 

- The BSS must support PFM, Packet Flow Management, procedures. 



5.5.2.4 



GERAN A/Gb mode to E-UTRAN Inter RAT handover 
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5.5.2.4.2 



Preparation phase 
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Figure 5.5.2.4.2-1 : GERAN A/Gb mode to E-UTRAN inter RAT HO, preparation phase 

1. The source access system, Source BSS, decides to initiate an Inter-RAT Handover to the E-UTRAN. At this 
point both upHnk and downlink user data is transmitted via the following: Bearers between UE and Source BSS, 
BSSGP PEC tunnel(s) between source BSS and source SGSN, OTP tunnel(s) between Source SGSN, Serving 
GW and PDN GW. 

NOTE 1 : The process leading to the handover decision is outside of the scope of this specification. 

2. The source BSS sends the message PS handover Required (TLLI, Cause, Source Cell Identifier, Target eNodeB 
Identifier, Source to Target Transparent Container (RN part), and active PECs list) to Source SGSN to request 
the CN to establish resources in the Target eNodeB, Target MME and the Serving GW. 

3. The Source SGSN determines from the 'Target eNodeB Identifier' IE that the type of handover is IRAT PS 
Handover to E-UTRAN. The Source SGSN initiates the Handover resource allocation procedure by sending 
message Eorward Relocation Request (IMSI, Target Identification, MM Context, PDP Context, SGSN Tunnel 
Endpoint Identifier for Control Plane, SGSN Address for Control plane. Source to Target Transparent Container 
(RN part). Packet Elow ID, SNDCP XID parameters, LLC XID parameters, and Direct Eorwarding Elag) to the 
target MME. When ISR is activated the message should be sent to the MME that maintains ISR for the UE when 
this MME is serving the target identified by the Target Identification. This message includes all PDP contexts 
that are established in the source system indicating the PEIs and the XID parameters related to those PDP 
Contexts, and the uplink Tunnel endpoint parameters of the Serving GW. 

The PDP Contexts shall be sent in a prioritized order, i.e. the most important PDP Context first. The 
prioritization method is implementation dependent, but should be based on the current activity. 

NOTE 2: Assigning the highest priority to the PDP context without TET could be done to get service continuity for 
all ongoing services regardless of the number of supported EPS bearers in the UE and network. 

The 'Direct Eorwarding Elag' IE indicates if Direct Eorwarding of data to Target side shall be used or not. This 
flag is set by the source SGSN. The target MME maps the PDP contexts to the EPS bearers 1-to-l and maps the 
pre-Rel-8 QoS parameter values of a PDP context to the EPS QoS parameter values of an EPS bearer as defined 
in Annex E. The MME establishes the EPS bearer(s) in the indicated order. The MME deactivates the EPS 
bearers which cannot be established. 

The MM context contains security related information, e.g. supported ciphering algorithms as described in 
TS 29.060 [14]. The relation between GSM and EPS security parameters is EES. 
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Editor's note: It is FFS if the EPS bearers are mapped 1:1 to PDP contexts. It is FES how the mapping is done. It is 
EES how the bearer identifiers are mapped. 

Eor the PDP Context with traffic class equals 'Background', the source SGSN shall indicate via the Activity 
Status Indicator IE that EPS bearers shall be established on the target side. 

4. The target MME determines if the Serving GW is relocated, e.g. due to PLMN change. If the Serving GW is 
relocated, the target MME selects the target Serving GW as described under clause 4.3.8.2 on "Serving GW 
selection function". The target MME sends a Create Bearer Request message (IMSI, MME Tunnel Endpoint 
Identifier for Control Plane, MME Address for Control plane, PDN GW address(es) for user plane, PDN GW 
UL TEID(s) for user plane, PDN GW address for control plane, and PDN GW TEID(s) for control plane, the 
Protocol Type over S5/S8) to the target Serving GW. The Protocol Type over S5/S8 is provided to Serving GW 
which protocol should be used over S5/S8 interface. 

4a. The target Serving GW allocates its local resources and returns them in a Create Bearer Response (Serving GW 
address(es) for user plane. Serving GW UL TEID(s) for user plane. Serving GW Address for control plane. 
Serving GW TEID for control plane) message to the target MME. 

5. The Target MME will request the Target eNodeB to establish the Bearer(s) by sending the message Handover 
Request (UE Identifier, Cause, Integrity protection information (i.e. IK and allowed Integrity Protection 
algorithms). Encryption information (i.e. CK and allowed Ciphering algorithms), EPS Bearers to be setup list. 
Source to Target Transparent Container). The Target MME shall not request resources for which the Activity 
Status Indicator within a PDP Context indicates that no active bearer exists on the source side for that PDP 
Context. 

Eor each EPS bearer requested to be established, 'EPS Bearers To Be Setup' IE shall contain information such as 
ID, bearer parameters. Transport Layer Address, and SI Transport Association. The Transport Layer Address is 
the Serving GW Address for user data, and the SI Transport Association corresponds to the uplink Tunnel 
Endpoint Identifier Data. 

The ciphering and integrity protection keys will be sent transparently from the target eNodeB to the UE in the 
Target to Source Transparent Container, and in the message PS Handover Command from source BSS to the UE. 
This will then allow data transfer to continue in the new RAT/mode target cell without requiring a new AKA 
(Authentication and Key Agreement) procedure. 

5 a. The Target eNodeB allocates the request resources and returns the applicable parameters to the Target MME in 
the message Handover Request Acknowledge (Target to Source Transparent Container, EPS Bearers setup list, 
EPS Bearers failed to setup list). Upon sending the Handover Request Acknowledge message the target eNodeB 
shall be prepared to receive downlink GTP PDUs from the Serving GW for the accepted EPS bearers. 

6. If indirect forwarding and relocation of Serving GW applies, the target MME sends a Create Bearer Request 
message (IMSI, MME Tunnel Endpoint Identifier for Control Plane, MME Address for Control plane. Target 
eNodeB Address(es), TEID(s) for DL user plane) to the target Serving GW. 

6a. The target Serving GW returns a Create Bearer Response (Cause, Serving GW DL TEID(s)) message to the 
target MME. 

7. The Target MME sends the message Forward Relocation Response (Cause, List of Set Up PECs, MME Tunnel 
Endpoint Identifier for Control Plane, Sl-AP cause, MME Address for control plane. Target to Source 
Transparent Container, Address(es) and TEID(s) for Data Forwarding, Serving GW change indication) to the 
Source SGSN. Serving GW change indication indicates a new Serving GW has been selected. 

If 'Direct Forwarding' is applicable, then the lEs 'Address(es) and TEID(s) for Data Forwarding' contains the DL 
GTP-U tunnel endpoint parameters to the eNodeB. Otherwise the lEs 'Address(es) and TEID(s) for Data 
Forwarding' contains the DL GTP-U tunnel endpoint parameters to the Target eNodeB or to the Target Serving 
GW in case of Serving GW re-location. 

8. If "Direct Forwarding" is not applicable, the source SGSN shall send the message Create Bearer Request (Cause, 
Address(es) and TEID(s) for Data Forwarding (see step 7), NSAPI(s)) to the Serving GW used for indirect 
packet forwarding. The Cause shall indicate that the Bearer is subject to data forwarding. 

Indirect forwarding may be performed via a Serving GW which is different from the Serving GW used as the 
anchor point for the UE. 
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8a. The Serving GW returns the forwarding user plane parameters by sending the message Create Bearer Response 
(Cause, Serving GW Address(es) and TEID(s) for Data Forwarding). If the Serving GW doesn't support data 
forwarding, an appropriate cause value shall be returned and the Serving GW Address(es) and TEID(s) will not 
be included in the message. 
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Figure 5.5.2.4.3-1 : GERAN A/Gb mode to E-UTRAN Inter RAT HO, execution phase 

NOTE: For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402 [2]. Steps 9 and 9a concern GTP 
based S5/S8. 

The source SGSN continues to receive downlink and uplink user plane PDUs. 

When source SGSN receives the Forward Relocation Response message it may start downlink N-PDU relay and 
duplication to the target eNodeB (in case of Direct Forwarding) or via the Serving GW (in case Indirect Forwarding), 
and the target eNodeB may start blind transmission of downlink user data towards the UE over the allocated radio 
channels. 

1. The Source SGSN completes the preparation phase towards Source BSS by sending the message PS HO 
Required Acknowledge (TLLI, List of Set Up PFCs, Target to Source Transparent Container). This message 
includes all PFIs that could be established on the Target side. 
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Before sending the PS Handover Required Acknowledge message, the source SGSN may suspend downlink data 
transfer for any PDP contexts. 

Before sending the PS Handover Command message to the UE the source BSS, may try to empty the downUnk 
BSS buffer for any BSS PFCs. 

2. The Source BSS will command the UE to handover to the target eNodeB via the message PS Handover 
Command. The access system specific message to UE includes a transparent container including radio aspect 
parameters that the Target eNodeB has set-up in the preparation phase. The procedures for this are FES. 

3. Source SGSN informs the Target MME/Target eNodeB regarding source access system contexts in the message 
Forward SRNS Context. 

The need for this step is EES. 

4. The UE moves to the E-UTRAN and performs access procedures toward Target eNodeB. 

5. When the UE has got access to Target eNodeB it sends the message HO to E-UTRAN Complete. 

6. When the UE has successfully accessed the Target eNodeB, the Target eNodeB informs the Target MME by 
sending the message Handover Notify. 

7. Then the Target MME knows that the UE has arrived to the target side and Target MME informs the Source 
SGSN by sending the Forward Relocation Complete (ISR, Serving GW change) message. ISR indicates whether 
the target MME maintains ISR after the handover, which is only possible when the S-GW is not changed. The 
Source SGSN will also acknowledge that information. When the Forward Relocation Complete message has 
been received and there is no longer any need for the SGSN to forward data, the SGSN stops data forwarding. A 
timer in source SGSN is started to supervise when resources in the Source Serving GW (in case of Serving GW 
relocation) shall be released. 

8. The Target MME will now complete the Handover procedure by informing the Serving GW (for Serving GW 
relocation this will be the Target Serving GW) that the Target MME is now responsible for all the EPS bearers 
the UE have established. This is performed in the message Update Bearer Request (Cause, MME Tunnel 
Endpoint Identifier for Control Plane, EPS Bearer ID(s), MME Address for Control Plane, eNodeB Address(es) 
and TEID(s) for User Traffic for the accepted EPS bearers, PDN GW addresses and TEIDs (for GTP-based 
S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN GW(s) for uplink traffic and RAT type). 

In case any EPS bearers are to be released the MME triggers the bearer release procedure as specified in 
clause 5.4.4.2. 

9. The Serving GW (for Serving GW relocation this will be the Target Serving GW) informs the PDN GW(s) the 
change of, for example, for Serving GW relocation or the RAT type, that e.g. can be used for charging, by 
sending the message Update Bearer Request. The PDN GW must acknowledge the request with the message 
Update Bearer Response. 

If PCC infrastructure is used, the PDN GW informs the PCRE about the change of, for example, the RAT type. 

10. The Serving GW (for Serving GW relocation this will be the Target Serving GW) acknowledges the user plane 
switch to the Target MME via the message Update Bearer Response (Cause, Serving GW Tunnel Endpoint 
Identifier for Control Plane, Serving GW (for Serving GW relocation this will be the Target Serving GW) 
Address for Control Plane, Protocol Configuration Options, PDN GW addresses and TEIDs (for GTP-based 
S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN GW(s) for uplink traffic). At this stage the user plane 
path is established for all bearers between the UE, Target eNodeB, Serving GW (for Serving GW relocation this 
will be the Target Serving GW) and PDN GW. 

1 1. When the timer started in step 7 expires the Source SGSN will clean-up all its resources towards Source BSS by 
performing the BSS Packet Flow Delete procedure. 

12. The RAN triggers the UE to initiate a Tracking Area Update procedure with the target MME. It is RAN 
functionality to provide the ECM-CONNECTED UE with the trigger information. 

The target MME knows that an IRAT Handover has been performed for this UE as it received the bearer 
context(s) by handover messages and therefore the target MME performs only a subset of the TA update 
procedure, specifically it excludes the context transfer procedures between source SGSN and target MME. 
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13. When the timer started in step 7 expires and if the source SGSN received the Serving GW change indication in 
the Forward Relocation Response message, it deletes the EPS bearer resources by sending Delete Bearer Request 
(Cause, TEID) messages to the Source Serving GW. Cause indicates to the old Serving GW that the Serving GW 
changes and the old Serving GW shall not initiate a delete procedure towards the PDN GW. The Source Serving 
GW acknowledges with Delete Bearer Response (TEID) messages. If ISR is established on the S-GW then the 
S-GW deletes the bearer resources on the other old CN node by sending Delete Bearer Request message(s) to 
that CN node. If resources for indirect forwarding have been allocated then they are released. 



5.6 Network Assisted Cell Change 

Network Assisted Cell Change (NACC) is a means that enables better performance for packet data services upon inter- 
cell change for those networks that do not support PS Handover. It reduces the service interruption time for UEs in 
active mode upon cell change by providing in the source cell, prior to the cell change, system information of a target 
cell allowing packet access. 

Within the scope of this specification, NACC is applicable for inter-RAT cell changes from a source E-UTRAN cell 
towards a target GERAN cell. 



5.6.1 Architecture Principles for E-UTRAN to GERAN NACC 

Introducing NACC from E-UTRAN to GERAN follows the principles of the Network Assisted Cell Change between 
UTRAN and GERAN as described in TS 25.413 [22] and TS 23.060 [7]. It comprises the specification of the 
E-UTRAN GERAN RAN Information Management (RIM) procedures in E-UTRAN and GERAN CN and RAN nodes 
as depicted in figure 5.6-1. 



eNodeB 



E-UTRAN 



RIM Signaling 
S1 




Relaying RIM 
Signaling 



S3/Gn 



GERAN 




Gb/lu 




RIM Signaling 



Figure 5.6-1 : E-UTRAN to GERAN NACC basic network arcliitecture 

The support for the NACC from E-UTRAN to GERAN has the following impacts on E-UTRAN / GERAN architecture: 

- Affected nodes: BSC,eNB, MME, SGSN; 

- Affected network interfaces: Gb, lu, S3, Gn, SI; 

- Affected radio interfaces: Um and Uu. 
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5.6.2 RAN Information Management (RIM) procedures 

5.6.2.1 General 

The RAN Information Management (RIM) procedures provide a generic mechanism for the exchange of arbitrary 
information between appHcations belonging to the RAN nodes. The RAN information is transferred via the MME and 
SGSN core network node(s). In order to make the RAN information transparent for the Core Network, the RAN 
information is included in a RIM container that shall not be interpreted by the Core Network nodes. 

The RIM procedures are optional both in the RAN and the CN nodes. For the Gb interface the use of RIM procedures is 
negotiated at start/restart of the Gb link. For the lu interface there is no negotiation of using RIM procedures or not at lu 
link start/restart. 

The RAN information is transferred in RIM containers from the source RAN node to the destination RAN node by use 
of messages. Each message carrying the RIM container is routed and relayed independently by the core network 
node(s). Any relation between messages is transparent for the MME/SGSN, i.e. a request/response exchange between 
RIM applications, for example, is routed and relayed as two independent messages by the MME/SGSN. 

The interfaces which will be used are the Gb, the lu, the SI, Gn and the S3 interfaces. The RAN information in the RIM 
container shall be transparent for the Core Network. An MME or SGSN supporting the RIM procedures provides 
addressing, routeing and relaying functions. 

5.6.2.2 Addressing, routeing and relaying 

5.6.2.2.1 Addressing 

All the messages used for the exchange of RAN information contain the addresses of the source and destination RAN 
nodes. A BSS is addressed by Routeing Area Identity (RAI) + Cell Identity (CI) of one of its cells. An eNodeB is 
addressed by the Target eNodeB Identifier. 

5.6.2.2.2 Routeing 

The following description applies to all the messages used for the exchange of RAN information. 

The source RAN node sends a message to its MME or SGSN including the source and destination addresses. The 
SGSN/MME uses the destination address to route the message encapsulated in a GTP message to the correct 
MME/SGSN via the S3 or Gn interface. 

The MME/SGSN connected to the destination RAN node decides which RAN node to send the message to based on the 
destination address. 

5.6.2.2.3 Relaying 

The SGSN performs relaying between BSSGP messages, RANAP messages and GTP messages as described in 
TS 48.018 [42], TS 25.413 [22], TS 29.060 [14] and TS 29.274 [43]. The MME performs relaying between SI and 
S3/Gn messages as described in TS 36.413 [36] and TS 29.274 [43] / TS 29.060 [14]. 

5.6.2.3 Applications using the RIM Procedures 

The RAN node applications, which use the RIM procedures, are fully transparent for the MME and SGSN. These 
applications are described in RAN specifications. An example is the Network Assisted Cell Change described in 
TS 48.018 [42], TS 25.413 [22] and TS 36.413 [36]. 

5.7 Information storage 

This clause describes information storage structures required for the EPS when 3GPP access only is deployed. 
Information storage for the case where non 3GPP accesses are deployed is in TS 23.402 [2] 
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5.7.1 HSS 

IMSI is the prime key to the data stored in the HSS. The data held in the HSS is defined in Table 5.7.1-1 here below. 
The table below is applicable to E-UTRAN in standalone operation only. 



Table 5.7.1-1: HSS data 



Field 


Description 


Status 


IMSI 


IMSI is the main reference key. 




MSISDN 


The basic MSISDN of the UE (Presence of MSISDN is optional). 




IMEI/IMEISV 


International Mobile Equipment Identity - Software Version 






Number 




MME Address 


The IP address of the MME currently serving this MS. 




MS PS Purged from EPS 


Indicates that the EMM and ESM contexts of the UE are deleted 
from the MME. 




ODB parameters 


Indicates that the status of the operator determined barring 




Access Restriction 


Indicates the access restriction subscription information. 


FFS 


Subscribed-UE-AMBR 


The Maximum Aggregated MBR to be provided across all Non- 
GBR bearers according to the subscription of the user. 




APN-OI Replacement 


Indicates the domain name to replace the APN 01 when 
constructing the PDN GW FQDN upon which to perform a DNS 
resolution. This replacement applies for all the APNs in the 
subscriber's profile. 




Each subscription profile contains one or more PDN subscription contexts: 


Context Identifier 


Index of the PDN subscription context. 




PDN Address 


Indicates subscribed IP address(es). 




Access Point Name (APN) 


A label according to DNS naming conventions describing the 
access point to the packet data network. 




EPS subscribed QoS profile 


The bearer level QoS parameter values for that APN's default 
bearer (QCI and ARP) and APN-AMBR (see clause 4.7.3). 




VPLMN Address Allowed 


Specifies whether for this APN the UE is allowed to use the PDN 
GW in the domain of the HPLMN only, or additionally the PDN GW 
in the domain of the VPLMN. 




PDN GW identity 


The identity of the PDN GW used for this APN. The PDN GW 
identity may be an FQDN, an IP address, or both. The PDN GW 
identity refers to a specific PDN GW. 




PDN GW Allocation Type 


Indicates whether the PDN GW is statically allocated or 
dynamically selected by other nodes. A statically allocated PDN 
GW is not changed during PDN GW selection. 





NOTE 1: IMEI and SVN are stored in HSS when the Automatic Device Detection feature is supported, see 
subclause 15.5 of TS 23.060 [7]. 

NOTE 2: The 'EPS subscribed QoS profile' stored in HSS is complementary to the legacy 'GPRS subscribed QoS 
profile'. 

NOTE 3: In order to avoid impacts on the current GPRS roaming environment (including that used on the GRX 

network), such format as "*.mnc<MNC>.mcc<MCC>.gprs" for the value of APN-OI Replacement is be 
required. 

Editor's note: The "Status" columns will be removed when the FFS's are resolved. 

Editor's note: How to store the information that a PDN subscription context is the default one is FFS. 

5.7.2 MME 

The MME maintains MM context and EPS bearer context information for UEs in the ECM-IDLE, ECM-CONNECTED 
and EMM-DEREGISTERED states. Table 5.7.2-1 shows the context fields for one UE. 
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Table 5.7.2-1 : MME MM and EPS bearer Contexts 



Field 


Description 


Status 


IMSI 


IMSI (International Mobile Subscriber Identity) is the subscribers 






permanent identity. 




MSISDN 


The basic MSISDN of the UE. The presence is dictated by its 






storage in the HSS. 




MM State 


Mobility management state ECM-IDLE, ECM-CONNECTED, 






EMM-DEREGISTERED. 




GUTI 


Globally Unique Temporary Identity. 




ME Identity 


Mobile Equipment Identity - (e.g. IMEI/IMEISV) Software Version 






Number 




Tracking Area List 


Current Tracking area list 




Cell Global Identity 


Last known cell 




^^tf^ll 1 ^ tf^ l^-l-l-l-l # A y-M /-^ 

ueii laentity Age 


Time elapsed since the last Cell Global Identity was acquired 




Authentication Vector 


Temporary authentication and key agreement data that enables 






an MME to engage in AKA with a particular user. An EPS 






Authentication Vector consists of four elements: 






cX) 1 IclVVUi l\ Ui Icillcl ly c rirAINILJ, 






an pxnprtpd rp^nnn^p XRF5^ 






C) Key kasmes 






d) a network authentication token AUTN. 




UE Radio Access Caoabilitv 


UE radio accp<?«5 canabilitip«5 




UE Network Capability 


UE network capabilities including security algorithms and key 






derivation functions supported by the UE 




Selected NAS Algorithm 


Selected NAS security algorithm 




Selected AS Alnorithm 


Qp|pr>fpr| AQ cpnuritv alnnrithm^ 




f^olASME 


i\ey oei loeniiTier lor ine main Key Ixasme 




Kasme 


Main key for E-UTRAN key hierarchy based on CK, IK and 




Serving network identity 




NAb Keys and COUN 1 


KNASint, K_NASenc> ^^d NAS COUNT parameter. 




1 J. 1 K 1 J. ■ 1 

Selected CN operator id 


1 J. 1 J. 1 J. ■ 1 J-'J. /j. J. A 1 

Selected core network operator identity (to support network 






snaring as oeTinea in i o ^o.^o i [^^jj. 




necovery 


inaicaies it ine noo is periorming aaiauase recovery. 




Access nesiricTion 


1 ne access resiriciion suuscripiion inTormaiion. 




ODB for PS parameters 


Indicates that the status of the operator determined barring for 






packet oriented services. 




KyiK/IF IP arlrlrocc fnr Q1 1 

iviivic ir auurebo iur oi i 


K/IK/IP IP arlrlrocc fnr tho Q1 1 intorfano /i icorl h\/ Q ^^\A/^ 

iviivic Ir duurebb lur uie oi i iiueiidue \ubeu uy o-ovvj 




1 VII VIC 1 ciu lur o 1 1 


iviivic 1 uiiiiei ciiupuiiu lueruiiier lui o i i irueriace. 




O OVV Ir dUUiUbb lUl OI 1 


Q-r^\A/ IP arlHrocc fnr tho Q1 1 intorfano /i icoH h\/ K/IK/IF^ 
O OVV Ir dUUiUbb lUi ulU OI 1 IlllcildUc ^UbcU Uy IVIIVICj 




S-GW TElDfor S11 


S-GW Tunnel Endpoint Identifier for the S1 1 interface. 




eNodeB Address in Use 


The IP address of the eNodeB currently used. 




eNBUESIAPID 


Unique identity of the UE over the S1 interface within eNodeB. 




MMEUES1APID 


Unique identity of the UE over the S1 interface within MME. 




APN Restriction 


Denotes the restriction on the combination of types of APN for the 


FFS 




APN associated with this EPS bearer Context. 




Subscribed Charging 


e.g. Normal, prepaid, flat rate and/or hot billing. 




Characteristics 






For each active PDN connection: 




APN in Use 


The APN currently used. This APN shall be composed of the APN 






Network Identifier and the APN Operator Identifier. 




APN Subscribed 


The subscribed APN received from the HSS. 




IP Address(es) 


IPv4 and/or IPv6 address(es) 


FFS if these 






are stored. 


VPLMN Address Allowed 


Specifies whether the UE is allowed to use the APN in the domain 






of the HPLMN only, or additionally the APN in the domain of the 






VPLMN. 




PDN GW Address in Use 


The IP address of the PDN GW currently used for sending control 




(control plane) 


plane signalling. 




Location Change Report 


Need to communicate Cell or TAI to the PDN GW with this EPS 




Required 


bearer Context. 




EPS subscribed QoS profile 


The bearer level QoS parameter values for that APN's default 






bearer (QCI and ARP) and that APN's AMBR (see clause 4.7.3). 




PDN GWGRE Key for 


PDN GW assigned GRE Key for the S5/S8 interface for the user 




uplink traffic (user plane) 


plane for uplink traffic. (For PMIP-based S5/S8 only) 
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Field 


Description Status 


For each EPS Bearer within the PDN connection 


EPS Bearer ID 


An EPS bearer identity uniquely identifies an EP S bearer for one 




UE accessing via E-UTRAN 


IP address for S1-u 


IP address of the S-GW for the S1-u interfaces. 


TElDforSlu 


Tunnel Endpoint Identifier of the S-GW for the S1-u interface. 


EPS bearer QoS parameters 


QCI and ARP 




optionally: GBR and MBR in case of GBR bearer 


EPS Bearer Charging 


e.g. Normal, prepaid, flat-rate and/or hot billing. 


Characteristics 




Charging Id 


Charging identifier, identifies charging records generated by SGW FFS 




and PDN GW. 


DLTFT 


Downlink Traffic Flow Template. (For PMIP-based S5/S8 only) 


ULTFT 


Uplink Traffic Flow Template. (For PMIP-based S5/S8 only) 



Editor's note: The" Status" columns will be removed when the FFS's are resolved. 



Editor's note: FFS how detached state security context caching is handled in E-UTRAN. 

5.7.3 Serving GW 

The Serving GW maintains the following EPS bearer context information for UEs. Table 5.7.3-1 shows the context 
fields for one UE. 
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Table 5.7.3-1 : SGW EPS bearer context 



Field 


Description 


E-UTRAN 


UTRAN/ 








GERAN 


IMSI 


IMSI (International Mobile Subscriber Identity) is the subscriber 


X 


X 




permanent identity. 






MSISDN 


The basic MSISDN of the UE. The presence is dictated by its 


X 


X 




storage in the HSS. 






Selected CN operator id 


Selected core network operator identity (to support network 


X 


X 




sharing as defined in TS 23.251 [24]). 






MMETEIDforSH 


MME Tunnel Endpoint Identifier for the S1 1 interface 


X 




MME IP address for S11 


MME IP address the S1 1 interface. 


X 




SGW TEID for S11/S4 


SGW Tunnel Endpoint Identifier for the S1 1 Interface and the 


X 


X 


(control plane) 


S4 Interface (control plane). 






SGW IP address forS11/S4 


SGW IP address for the S1 1 interface and the S4 Interface 


X 


X 


(control plane) 


(control plane). 






SGSN IP address for S4 


SGSN IP address for the S4 interface (Used by the S-GW). 




X 


(control plane) 








SGSN TEID for S4 (control 


SGSN Tunnel Endpoint Identifier for the S4 interface. 




X 


plane) 








Trace reference 


Identifies a record or a collection of records for a particular 


X 


X 


Trace type 


trace. 

Indicates the type of trace 


X 


X 


Trigger id 


Identifies the entity that initiated the trace 


X 


X 


OMC identity 


Identifies the OMC that shall receive the trace record(s). 


X 


X 


For each PDN Connection: 








NOTE: The following entries are repeated for each PDN. 






APN in Use 


The APN currently used. This APN shall be composed of the 


X 


X 




APN Network Identifier and the APN Operator Identifier. 






P-GW Address in Use 


The IP address of the P-GW currently used for sending control 


X 


X 


(control plane) 


plane signalling. 






P-GW TEID for S5/S8 


P-GW Tunnel Endpoint Identifier for the S5/S8 interface for the 


X 


X 


(control plane) 


control plane. 






S-GW IP address for S5/S8 


S-GW IP address for the S5/S8 for the control plane signalling. 


X 


X 


(control plane) 








S-GW TEID for S5/S8 


S-GW Tunnel Endpoint Identifier for the S5/S8 control plane 


X 


X 


(control plane) 


interface. 






APN Restriction 


Denotes the restriction on the combination of types of APN for 


X 


X 




the APN associated with this EPS bearer Context. 






For each EPS Bearer within 


the PDN Connection: 






NOTE: The following entries defining the EPS Bearer specific parameters are included within the set of parameters defining 


the PDN Connection. 








EPS Bearer Id 


An EPS bearer identity uniquely identifies an EPS bearer for 


X 


X 




one UE accessing via E-UTRAN 






ULTFT 


Uplink Traffic Flow Template 


X 


X 


DLTFT 


Downlink Traffic Flow Template 


X 


X 


P-GW Address in Use (user 


The IP address of the P-GW currently used for sending user 


X 


X 


plane) 


plane traffic. 






P-GW TEID for S5/S8 (user 


P-GW Tunnel Endpoint Identifier for the S5/S8 interface for the 


X 


X 


plane) 


user plane. 






S-GW IP address for S5/S8 


S-GW IP address for user plane data received from PDN GW. 


X 


X 


(user plane) 








S-GW TEID for S5/S8 (user 


S-GW Tunnel Endpoint Identifier for the GTP Based S5/S8 


X 


X 


plane) 


interface for user plane. 






S-GW IP address forS1-u 


S-GW IP address for the S1-u interface (Used by the eNodeB) 


X 




S-GW TEID for S1-U 


S-GW Tunnel Endpoint Identifier for the S1-u interface. 


X 




eNodeB IP address for S1-u 


eNodeB IP address for the S1-u interface (Used by the S-GW). 


X 




eNodeB TEID for S1-u 


eNodeB Tunnel Endpoint Identifier for the S1-u interface. 


X 




S-GW IP address forS12 


S-GW IP address for the S12 interface (Used by the RNC) 




X 


S-GW TEID for S1 2 


S-GW Tunnel Endpoint Identifier for the S12 interface. 




X 


RNC IP address forS12 


RNC IP address for the S12 interface (Used by the S-GW). 




X 


RNC TEID for S12 


RNC Tunnel Endpoint Identifier for the S12 interface. 




X 


S-GW IP address for S4 


S-GW IP address for the S4 interface (Used by the SGSN) 




X 


(user plane) 








S-GW TEID for S4 (user 


S-GW Tunnel Endpoint Identifier for the S4 interface. 




X 


plane) 








SGSN IP address for S4 


SGSN IP address for the S4 interface (Used by the S-GW). 




X 



ETSI 



3GPP TS 23.401 version 8.2.0 Release 8 



129 



ETSI TS 123 401 V8.2.0 (2008-10) 



Field 


Description 


E-UTRAN 


UTRAN/ 
GERAN 


(user plane) 








SGSN TElDfor S4 (user 


SGSN Tunnel Endpoint Identifier for the S4 interface. 




X 


plane) 








EPS Bearer QoS Profile 


ARP, GBR, MBR, QCI. 


X 


X 


Charging Id 


Charging identifier, identifies charging records generated by S- 
GW and PDN GW. 


X 


X 


Charging Characteristics 


Normal, prepaid, flat rate and/or hot billing 


X 


X 



Editor's note: The table needs to be reviewed to identify differences for PMIP based S5/S8. 



5.7.4 PDN GW 

The PDN GW maintains the following EPS bearer context information for UEs. Table 5.7.4-1 shows the context fields 
for one UE. 
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Table 5.7.4-1 : PGW context 



Field 


Description 


E-UTRAN 


UTRAN/ 








GERAN 


IMSI 


IMSI (International Mobile Subscriber Identity) is the 


X 


X 




subscriber permanent identity. 






MSISDN 


The basic MSISDN of the UE. The presence is dictated by its 


X 


X 




storage in the HSS. 






Selected CN operator id 


Selected core network operator identity (to support network 


X 


X 




sharing as defined in TS 23.251 [24]). 






RAT type 


Current RAT 


X 


X 


Trace reference 


Identifies a record or a collection of records for a particular 


X 


X 




trace. 






Trace type 


Indicates the type of trace 


X 


X 


Trigger id 


Identifies the entity that initiated the trace 


X 


X 


OMC identity 


Identifies the OMC that shall receive the trace record(s). 


X 


X 


For each APN in use: 








NOTE: The following entries are repeated for each APN. 






APN in use 


The APN currently used. The APN shall be composed of the 


X 


X 




APN Network Identifier and the APN Operator Identifier. 






APN-AMBR 


The APN-AMBR for this APN. 


X 


X 


For each PDN Connection within the APN: 






NOTE: The following entries are repeated for each PDN connection within the APN. 






IP Address(es) 


IPv4 address and/or IPv6 address 


X 


X 


PDN type 


IPv4, IPv6, or IPv4v6 


X 


X 


S-GW Address in Use 


The IP address of the S-GW currently used for sending 


X 


X 


(control plane) 


control plane signalling. 






S-GW TEID for S5/S8 


S-GW Tunnel Endpoint Identifier for the S5/S8 interface for 


X 


X 


(control plane) 


the control plane. 






P-GW IP address for S5/S8 


P-GW IP address for the S5/S8 for the control plane 


X 


X 


(control plane) 


signalling. 






P-GW TEID for S5/S8 


P-GW Tunnel Endpoint Identifier for the S5/S8 control plane 


X 


X 


(control plane) 


interface. 






SGSN support for 


Indicated that the SGSN serving the UE supports procedures 




X 


CGI/SAI/RAI change 


for reporting CGI/SAI/RAI changes (according to 23.060 [7] 






reporting 


clause 15.1.1a). 






CGI/SAI/RAI change report 


Denotes whether the SGSN is requested to send changes in 




X 


required 


CGI/SAI or RAI for this bearer 






BCM 


The negotiated Bearer Control Mode for GERAN/UTRAN. 




X 


For each EPS Bearer within the PDN Connection: 






NOTE: The following entries defining the EPS Bearer specific parameters are included within the set of parameters 


defining the PDN 


Connection. 






EPS Bearer Id 


An EPS bearer identity uniquely identifies an EPS bearer for 


X 


X 




one UE accessing via E-UTRAN 






ULTFT 


Uplink Traffic Flow Template 


X 


X 


DLTFT 


Downlink Traffic Flow Template 


X 


X 


S-GW Address in Use (user 


The IP address of the S-GW currently used for sending user 


X 


X 


plane) 


plane traffic. 






S-GW TEID for S5/S8 (user 


S-GW Tunnel Endpoint Identifier for the S5/S8 interface for 


X 


X 


plane) 


the user plane. 






P-GW IP address for S5/S8 


P-GW IP address for user plane data received from PDN 


X 


X 


(user plane) 


GW. 






P-GW TEID for S5/S8 (user 


P-GW Tunnel Endpoint Identifier for the GTP Based S5/S8 


X 


X 


plane) 


interface for user plane. 






EPS Bearer QoS Profile 


ARP, GBR, MBR, QCI. 


X 


X 


Charging Id 


Charging identifier, identifies charging records generated by 


X 


X 




S-GW and PDN GW. 






Charging Characteristics 


Normal, prepaid, flat rate and/or hot billing 


X 


X 



5.7.5 UE 

The UE maintains the following context information. Table 5.7.5-1 shows the context fields. A GERAN or UTRAN 
capable UE maintains in addition the context information as described in a similar UE context table in TS 23.060 [7] 
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Table 5.7.5-1: UE context 



Field 



Description 

IMSI (International Mobile Subscriber Identity) is the subscribers 
permanent identity. 
The basic MSISDN of the UE. 

Mobility management state EMM-REGISTERED, EMM- 
DEREGISTERED. 
Globally Unique Temporary Identity. 

Mobile Equipment Identity - (e.g. IMEI/IMEISV) Software Version 
Number. 

Current Tracking area list. 

A TAI which is contained in the TA list the UE registered to the 
network and which identifies the tracking area last visited by the 
UE. 

Selected NAS security algorithm. 
Selected AS security algorithms. 
Key Set Identifier for the main key Kasme. 
Main key for E-UTRAN key hierarchy based on CK, IK and 
Serving network identity. 
KNASint> KNASenc> ^nd NAS COUNT parameter. 
This parameter is used internally by the UE to memorise which 
temporary ID it has to indicate in the next RAU/TAU (P-TMSI, 
GUTI or RAT-related TMSI, the latter means P-TMSI in RAU and 
GUTI in TAU). 
For each active PDN connection: 

APN in Use The APN currently used. This APN shall be composed of the APN 

Network Identifier and the APN Operator Identifier. 
IP Address(es) IPv4 and/or IPv6 address(es). 



For each EPS Bearer within the PDN connection 

EPS Bearer ID An EPS bearer identity uniquely identifies an EPS bearer for one 

UE accessing via E-UTRAN. 
EPS bearer QoS parameters GBR and MBR in case of GBR bearer. 

UL TFT Uplink Traffic Flow Template. 



Status 



IMSI 

MSISDN 
EMM State 

GUTI 

ME Identity 

Tracking Area List 
last visited TAI 



Selected NAS Algorithm 
Selected AS Algorithm 

KSIasme 

Kasme 

NAS Keys and COUNT 
Temporary Identity used in 
Next update (TIN) 



FFS 



FFS if these 
are stored in 
MT. 



5.7a Charging 

Accounting functionality is provided by the SGW and the PDN GW. 

The Serving GW shall be able to collect for each UE accounting information, i.e. the amount of data transmitted in 
uplink and downlink direction categorized with the QCI and ARP pair per UE per PDN. 

The PDN GW shall be able to provide charging functionality for each UE according to TS 23.203 [6]. 

A PDN GW without a Gx interface shall be able to support flow based online and offline charging based on local 
configuration and interaction with the Online and Offline Charging Systems. 

Editor's note: It is FFS if the PDN GW in addition needs to receive charging characteristics from the Serving 
Gateway or another source. 



5.8 MBMS 

MBMS is a point- to -multipoint service in which data is transmitted from a single source entity to multiple recipients. 
Transmitting the same data to multiple recipients allows network resources to be shared. 

The Evolved MBMS supports two modes, MBMS Broadcast Mode and MBMS Enhanced Broadcast Mode as defined 
in TS 23.246 [13]. 



5.9 Interactions with other services 

NOTE: Specific support for emergency access and location services are out of scope of this Release. 
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5.9.1 Location Reporting Procedure 

This procedure is used by an MME to request the eNB to report where the UE is currently located. This procedure may 
be used for services that require accurate Cell ID (e.g. emergency calls, lawful intercept, charging). 

The details of Location Service architecture and procedures for EPS are not descibed in this Realease. 



eNB MME 




1 . Location reporting control 




< 

2. Location Report 


► 

3. Cancel location reporting 


^ 



Figure 5.9.1-1: Location Reporting Procedure 

1) The MME sends a Location Reporting Control message to the eNB. The Location Reporting Control message 
may contain information such as location information to be reported, reporting type, etc. Location information to 
be reported is Global Cell ID. Reporting Type indicates whether the message is intended to trigger a stand-alone 
report about the current Cell ID of the UE or start eNB report UE changed cell. 

2) The eNB sends a Location Report message informing the MME about the location of the UE which shall include 
the requested location information, i.e. the Global Cell ID. 

3) The MME can send a Cancel Location Reporting message to inform the eNB that it should terminate location 
reporting for a given UE. This message is needed only when the reporting was requested for a reporting period. 

Editor's note: Location reporting procedure upon X2 handover and MME relocation is FES. 

Editor's note: The full usage of this procedure for chaging is FES. 

5.10 Multiple-PDN support 

5.10.1 General 

The EPS shall support simultaneous exchange of IP traffic to multiple PDNs through the use of separate PDN GWs or 
single PDN GW. The usage of multiple PDNs is controlled by network policies and defined in the user subscription. 

The EPS shall support UE-initiated connectivity establishment in order to allow multiple PDN connections to one or 
more PDNs. It shall be possible for a UE to initiate disconnection from any PDN. 

All simultaneous active PDN connections of a UE that are associated with the same APN shall be provided by the same 
P-GW. 

UE support for multiple PDN connections is optional. 

5.10.2 UE requested PDN connectivity 

The UE requested PDN connectivity procedure for an E-UTRAN is depicted in figure 5.10.2-L The procedure allows 
the UE to request for connectivity to a PDN including allocation of a default bearer. The PDN connectivity procedure 
may trigger one or multiple Dedicated Bearer Establishment procedures to establish dedicated EPS bearer(s) for that 
UE. 
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Figure 5.10.2-1: UE requested PDN connectivity 

NOTE 1: For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402 [2]. Steps 3, 4, and 5 concern 
GTP based S5/S8. 



NOTE 2: The UE also uses this procedure to request re-estabUshment of existing PDN connectivity upon handover 
from non-3GPP accesses. 

NOTE 3: The steps in (B) and step 15 are executed only upon handover from non-3GPP access. 

NOTE 4: Steps 13 and 14 are performed only if the Request Type indicates "Initial Request". 

1 . The UE initiates the UE Requested PDN procedure by the transmission of a PDN Connectivity Request ( APN or 
Default APN indicator, PDN Type, Protocol Configuration Options, Request Type) message. If the UE was in 
ECM-IDLE mode, this NAS message is preceded by the Service Request procedure. PDN type indicates the 
requested IP version (IPv4, IPv4/v6, IPv6). The MME verifies that the APN provided by UE is allowed by 
subscription. If the UE provides an indicator requesting to use the Default APN instead of APN, the Default 
APN shall be used for the remainder of this procedure. Protocol Configuration Options (PCO) are used to 
transfer parameters between the UE and the PDN GW, and are sent transparently through the MME and the 
Serving GW. The Protocol Configuration Options may include the Address Allocation Preference, which 
indicates that the UE prefers to obtain an IPv4 address only after the default bearer activation by means of 
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DHCPv4. The Request Type indicates "initial request" if the UE requests new additional PDN connectivity over 
the 3GPP access network. In case of multiple PDN connections, the Request Type indicates "handover" when 
the UE is performing an handover from non-3 GPP access and the UE has already established connectivity with 
the PDN over the non-3 GPP access. 

Editor's note: An indicator for requesting use of the Default APN is to be defined during stage 3 works, e.g. a pre- 
defined string such as 'default' or lack of APN. This indicator should be known to all UEs. 

Editor's note: It's FES whether the other values of the PDN Address Allocation and related use should be 
considered. 

2. If the Request Type indicates "Handover", the MME uses the PDN GW stored in the Subscription Data retrieved 
by the MME during the authentication performed at attach. If the Request Type indicates "initial attach" the 
MME selects a PDN GW as described in clause 4.3.8.1 on PDN GW Selection Function (3GPP accesses), 
allocates a Bearer Id, and sends a Create Default Bearer Request (IMSI, MSISDN, MME TEID for control plane, 
RAT type, PDN GW address, PDN Address, Default Bearer QoS, PDN Type, PDN Address, APN-AMBR, 
APN, EPS Bearer Id, Protocol Configuration Options, Handover Indication, ME Identity, User Location 
Information (ECGI), Selection Mode, Charging Characteristics, Trace Reference, Trace Type, Trigger Id, OMC 
Identity, Maximum APN Restriction, Dual Address Bearer Flag) message to the Serving GW. 

The RAT type is provided in this message for the later PCC decision. The MSISDN is included if the MME has 
it stored for that UE. Handover Indication is included if the Request Type indicates "handover". Selection Mode 
indicates whether a subscribed APN was selected, or whether a non-subscribed APN sent by the UE or a non- 
subscribed APN chosen by the SGSN was selected. Selection Mode is set according to Annex A of 
TS 23.060 [7]. The P-GW may use Selection Mode when deciding whether to accept or reject the default bearer 
activation. For example, if an APN requires subscription, the P-GW is configured to accept only the default 
bearer activation that requests a subscribed APN as indicated by Selection Mode. Charging Characteristics 
indicates which kind of charging the bearer context is liable for. 

The charging characteristics for the PS subscription and individually subscribed APNs as well as the way of 
handling Charging Characteristics and whether to send them or not to the P-GW is defined in TS 32.251 [44]. 
The MME shall include Trace Reference, Trace Type, Trigger Id, and OMC Identity if S-GW and/or P-GW trace 
is activated. The MME shall copy Trace Reference, Trace Type, and OMC Identity from the trace information 
received from the HLR or OMC. 

The Maximum APN Restriction denotes the most stringent restriction as required by any already active bearer 
context. If there are no already active bearer contexts, this value is set to the least restrictive type (see clause 15.4 
of TS 23.060 [7]). If the P-GW receives the Maximum APN Restriction, then the P-GW shall check if the 
Maximum APN Restriction value does not conflict with the APN Restriction value associated with this bearer 
context request. If there is no conflict the request shall be allowed, otherwise the request shall be rejected with 
sending an appropriate error cause to the UE. 

In case the PDN subscription context contains a subscribed IPv4 address and/or IPv6 prefix, the MME indicates 
it in the PDN address. The Dual Address Bearer Flag shall be set when the UE requests PDN type IPv4v6 and all 
SGSNs which the UE may be handed over to are Release 8 or above supporting dual addressing, which is 
determined based on node pre-configuration by the operator 

3. The Serving GW creates a new entry in its EPS Bearer table and sends a Create Default Bearer Request (IMSI, 
MSISDN, Serving GW Address for the user plane. Serving GW TEID of the user plane. Serving GW TEID of 
the control plane, RAT type. Default Bearer QoS, PDN Type, PDN Address, APN-AMBR, APN, Bearer Id, 
Protocol Configuration Options, Handover Indication, ME Identity, User Location Information (ECGI), 
Selection Mode, Charging Characteristics, Trace Reference, Trace Type, Trigger Id, OMC Identity, Maximum 
APN Restriction, Dual Address Bearer Flag) message to the PDN GW indicated in the PDN GW address 
received in the previous step. After this step, the Serving GW buffers any downlink packets it may receive from 
the PDN GW until receives the message in step 1 1 below. The MSISDN is included if received from the MME. 
If the Handover Indication is included, the Serving GW includes it in the Create Default Bearer Request 
message. 

4. If the Request Type indicates "Initial Request", the PDN GW may employ an IP-CAN Session Establishment 
procedure as defined in TS 23.203 [6] with the PCRF to get the default PCC rules for the UE if PCRF is appHed 
in the network. This may optionally lead to the establishment of a number of dedicated bearers following the 
procedures defined in clause 5.4.1 in association with the establishment of the default bearer which is described 
in Annex F. 
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The RAT type is provided to the PCRF by the PDN GW if received by the previous message. If the PDN 
GW/PCEF is configured to activate predefined FCC rules for the default bearer, the interaction with the PCRF is 
not required (e.g. operator may configure to do this) at the moment. 

If the the Request Type indicates "Handover", the PDN GW executes a PCEF-Initiated IP-CAN Session 
Modification procedure with the PCRF as specified in TS 23.203 [6] to obtain the rules required for the PDN 
GW in the VPLMN or HPLMN to function as the PCEF for all the active sessions the UE has established with 
the new IP-CAN type as a result of the handover procedure. 

If the updated PCC rules require establishment of dedicated bearer for the UE, the establishment of those bearers 
takes place before step 11. The establishment of dedicated bearers in combination with the default takes place as 
described in Annex F. 

5. The P-GW creates a new entry in its EPS bearer context table and generates a Charging Id. The new entry allows 
the P-GW to route user plane PDUs between the S-GW and the packet data network, and to start charging. The 
way the P-GW handles Charging Characteristics that it may have received is defined in TS 32.251 [44]. 

The PDN GW returns a Create Default Bearer Response (PDN GW Address for the user plane, PDN GW TEID 
of the user plane, PDN GW TEID of the control plane, PDN Type, PDN Address, EPS Bearer Id, Protocol 
Configuration Options, UL TFT, Charging Id, Prohibit Payload Compression, APN Restriction, Cause, 
CGI/SAI/RAI change report required, BCM) message to the Serving GW. The PDN GW takes into account the 
PDN type sent by the UE, the Dual Address Bearer Flag and the policies of operator when the PDN GW selects 
the PDN type to be used as follows. If the UE has requested PDN type IPv4v6 and both IPv4 and IPv6 
addressing are possible in the PDN but the Dual Address Bearer Flag is not set, or only single IP version 
addressing is possible in the PDN, the PDN GW selects a single IP version (either IPv4 or IPv6). If the UE has 
requested PDN type IPv4 or IPv6, the PDN GW uses the PDN type supplied by the UE in case it is supported in 
the PDN, otherwise an appropriate error cause will be returned. The PDN GW allocates a PDN Address 
according to the selected PDN Type. In case the PDN GW has selected a PDN type different from the one sent 
by the UE, the PDN GW indicates together with the PDN type IE a reason cause (network preference, single 
address bearers only) to the UE why the PDN type has been modified. PDN Address may contain an IPv4 
address for IPv4 and/or an IPv6 prefix and an Interface Identifier. If the PDN has been configured by the 
operator so that the PDN addresses for the requested APN shall be allocated by usage of DHCPv4 only, or if the 
PDN GW allows the UE to use DHCPv4 for address allocation according to the Address Allocation Preference 
received from the UE, the PDN Address shall be set to 0.0.0.0, indicating that the IPv4 address shall be 
negotiated by the UE with after completion of the Default Bearer Activation procedure. In case of external PDN 
addressing for IPv6, the PDN GW obtains the IPv6 prefix from the external PDN using either RADIUS or 
Diameter client function. In the PDN Address field of the Create Default Bearer Response, the PDN GW 
includes the Interface Identifer and IPv6 prefix. The PDN GW sends Router Advertisement to the UE after 
default bearer establishment with the IPv6 prefix information for all cases. If the PDN address is contained in the 
Create Default Bearer Request, the PDN GW shall allocate the IPv4 addresss and/or IP6 prefix contained in the 
PDN address to the UE. If Handover Indication indicates "Handover", the PDN Address Information shall 
contain the same IP address the UE obtained during PDN connectivity establishment over the non-3 GPP access. 
Protocol Configuration Options contains the BCM as well as optional PDN parameters that the P-GW may 
transfer to the UE. BCM shall also be sent as a separate IE. These optional PDN parameters may be requested by 
the UE, or may be sent unsolicited by the P-GW. Protocol Configuration Options are sent transparently through 
the MME. According to the used RAT BCM is set to "UE/network". 

6. If the CGI/SAI/RAI change report required is received for this bearer context, then the S-GW shall store this for 
the bearer context and the S-GW shall report to that P-GW whenever a CGI/SAI/RAI change occurs that meets 
the P-GW request, as described in clause 15.1.1a of TS 23.060 [7]. 

The Serving GW returns a Create Default Bearer Response (PDN Type, PDN Address, Serving GW address for 
User Plane, Serving GW TEID for User Plane, Serving GW TEID for control plane, EPS Bearer Id, Protocol 
Configuration Options, UL TFT, DL TFT (for PMIP-based S5/S8), Charging Id, Prohibit Payload Compression, 
APN Restriction, Cause, CGI/SAI/RAI change report required, BCM) message to the MME. The DL TFT for 
PMIP-based S5/S8 is obtained from interaction between the Serving GW and the PCRF as described in clause 
5.6.1 of TS 23.402 [2], when PCC is deployed; otherwise, the DL TFT IE is wildcarded, matching any downlink 
traffic. If the UE indicates the Request Type as "Handover", this message also serves as an indication to the 
MME that the S5 bearer setup and update has been successful. At this step the GTP tunnel(s) over S5 are 
established. 

7. If an APN Restriction is received, then the MME shall store this value for the Bearer Context and the MME shall 
check this received value with the stored value for the Maximum APN Restriction to ensure there are no 
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conflicts between values. If the consequence of this check results in the PDN connectivity being rejected, the 
MME shall initiate a Bearer Deactivation and return an appropriate error cause. If the PDN Connectivity 
Request is accepted, the MME shall determine a (new) value for the Maximum APN Restriction. If there is no 
previously stored value for Maximum APN Restriction, then the Maximum APN Restriction shall be set to the 
value of the received APN Restriction. 

If the CGI/SAI/RAI change report required is received for this bearer context, then the MME shall store this for 
the bearer context and the MME shall report whenever a CGI/SAI/RAI change occurs that meets the request, as 
described in clause 15.1.1a of TS 23.060 [7]. 

The MME sends PDN Connectivity Accept (APN, PDN Type, PDN Address, EPS Bearer Id) message to the 
eNodeB. This message is contained in an S1_MME control message Bearer Setup Request (Default EPS Bearer 
QoS, PDN Connectivity Accept, Session Management Configuration, Sl-TEID, Protocol Configuration 
Options). This SI control message includes the TEID at the Serving GW used for user plane and the address of 
the Serving GW for user plane. The MME includes the UL TFT and the EPS Bearer QoS parameter QCI into the 
Session Management Configuration IE. Furthermore, if the UE has UTRAN or GERAN capabilities, the MME 
uses the EPS bearer QoS information to derive the corresponding PDP context parameters QoS Negotiated (R99 
QoS profile). Radio Priority and Packet Flow Id and includes them in the Session Management Configuration. If 
the UE indicated in the UE Network Capability it does not support BSS packet flow procedures, then the MME 
shall not include the Packet Flow Id. MME will not send the SI Bearer Setup Request message until any 
outstanding SI Bearer Setup Response message for the same UE has been received or timed out. If the APN- 
AMBR has changed the MME may update the used UE-AMBR if appropriate. The MME may provide the 
eNodeB with Handover Restriction List. Handover Restriction List is described in clause 4.3.5.7 "Mobility 
Restrictions". 

8. The eNodeB sends RRC Connection Reconfiguration to the UE including the Session Management 
Configuration IE, and the PDN Connectivity Accept message will be sent along to the UE. The UE shall ignore 
the IPv6 prefix information in PDN Address. The UE uses the uplink packet filter (UL TFT) to determine the 
mapping of uplink packets to the radio bearer. The UE may provide EPS Bearer QoS parameters to the 
application handling the service data flow. The application usage of the EPS Bearer QoS is implementation 
dependent. The UE shall not reject the RRC Connection Reconfiguration on the basis of the EPS Bearer QoS 
parameters contained in the Session Management Configuration IE. 

NOTE 2: The IP address allocation details are described in clause 5.3.1 on "IP Address Allocation". 

9. The UE sends the RRC Connection Reconfiguration Complete to the eNodeB. 

10. The eNodeB send an S1_MME control message Bearer Setup Response to the MME. The SI control message 
includes the TEID of the eNodeB and the address of the eNodeB used for downlink traffic on the S1_U reference 
point. 

After the PDN Connectivity Accept message and once the UE has obtained a PDN Address Information, the UE 
can then send uplink packets towards the eNodeB which will then be tunnelled to the Serving GW and PDN 
GW. If the UE requested for a dual address PDN type (IPv4v6) to a given APN and was granted a single address 
PDN type (IPv4 or IPv6) by the network with a reason cause "single address bearers only", the UE may request 
for the activation of a parallel PDN connection to the same APN with a single address PDN type (IPv4 or IPv6) 
other than the one already activated. If the UE receives no reason cause in step 8 in response to a IPv4v6 PDN 
type and it receives an IPv6 prefix and Interface Identifier apart from the IPv4 address or 0.0.0.0 in the PDN 
Address field, it considers that the request for a dual address PDN was successful. It can wait for the Router 
Advertisement from the network with the IPv6 prefix information or it may send Router Solicitation if necessary. 

1 1. The MME sends an Update Bearer Request (eNodeB address, eNodeB TEID, Handover Indication) message to 
the Serving GW. If Request Type indicates "handover", the Handover Indication is also included. 

11a. If the Handover Indication is included in step 1 1, the Serving GW sends an Update Bearer Request message 
to the PDN GW to prompt the PDN GW to tunnel packets from non 3GPP IP access to 3GPP access system and 
immediately start routing packets to the Serving GW for the default and any dedicated EPS bearers established. 

1 lb. The PDN GW acknowledges by sending Update Bearer Response to the Serving GW. 

12. The Serving GW acknowledges by sending Update Bearer Response (EPS Bearer Identity) to the MME. The 
Serving GW can then send its buffered downlink packets. EPS Bearer Identity is included if the Request Type 
indicates "handover". 
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13. After the MME receives Update Bearer Response in step 13, if an EPS bearer was established and if the 
subscription data indicates that the user is allowed to perform handover to non-3 GPP accesses and if this is the 
first PDN connection associated with this APN, the MME shall send an Update Location Request including the 
PDN GW address and the APN to the HSS for mobility with non-3GPP accesses. 

14. The HSS stores the PDN GW identity and the associated APN, and sends an Update Location Response to the 
MME. 

15. If the Request Type indicates "handover", the PDN GW shall initiate resource allocation deactivation procedure 
in the trusted/untrusted non-3GPP IP access as specified in TS 23.402 [2]. 



5.10.3 UE requested PDN disconnection 



The UE requested PDN disconnection procedure for an E-UTRAN is depicted in figure 5.10.3-1. The procedure allows 
the UE to request for disconnection from one PDN. Bearers including the default bearer of this PDN shall be deleted 
during this procedure. 
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Figure 5.10.3-1: UE requested PDN disconnection 



NOTE: For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402 [2]. Steps 3, 4 and 5 concern GTP 
based S5/S8. 



1. The UE initiates the UE requested PDN disconnection procedure by the transmission of a PDN Disconnection 
Request (LBI) message. The LBI indicates the default bearer associated with the PDN connection being 
disconnected. If the UE was in ECM-IDLE mode, this NAS message is preceded by the Service Request 
procedure. 

2. The EPS Bearers in the Serving GW regarding this particular UE and the PDN are deactivated by the MME by 
sending Delete Bearer Request (TEID, LBI) to the Serving GW. 

3. The Serving GW sends Delete Bearer Request (TEID, LBI) to the PDN GW. 

4. The PDN GW acknowledges with Delete Bearer Response. 

5. The PDN GW employs the PCRF-initiated IP-CAN Session Termination procedure as defined in TS 23.203 [6] 
with the PCRF to indicate to the PCRF that EPS Bearer is released if PCRF is applied in the network. 

6. The Serving GW acknowledges with Delete Bearer Response. 

7. The MME initiates the deactivation of the Bearers associated with the PDN to the eNodeB. The MME shall 
provide the UE-AMBR to the eNodeB unless all of the bearers belonging to the UE are released. The eNodeB 
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releases the corresponding radio bearers, and sends an acknowledgement of the deactivation to the MME. PDN 
Disconnection Response is piggybacked to the UE in this step. 

8. If the subscription data indicates that the user is allowed to perform handover to non-3GPP accesses, the MME 
sends Update Location Request to the HSS to delete the PDN GW address information for the given APN if the 
PDN GW identity was dynanucally alocated. 

9. The HSS deletes PDN GW identity for the given APN and sends an Update Location Response to the MME. 

If all the bearers belonging to a UE are released, the MME and the UE shall change the MM state to EMM- 
DEREGISTERED and the MME sends the SI Release Command to the eNodeB, which initiates the release of the RRC 
connection for the given UE if it is not released yet, and returns an SI Release Complete message to the MME. 

5.1 1 UE Capability Handling 

The UE Capability information is made up of the UE Radio Capability information and the UE Core Network 
Capability information. 

The UE Radio Capability information contains information on RATs that the UE supports (e.g. power class, frequency 
bands, etc). Consequently, as this information can be sufficiently large (e.g. >50 octets) it is undesirable to send it 
across the radio interface at every transition from ECM-IDLE to ECM-CONNECTED. To avoid this radio overhead, 
the MME stores the UE Capability information during ECM-IDLE state and the MME shall send its most up to date UE 
Radio Capability information to the E-UTRAN in the SI interface INITIAL CONTEXT SETUP REQUEST message. 

NOTE 1: This means that for a signalling only procedure such as a periodic Tracking Area Update, the UE Radio 
CapabiUty would not be sent to the E-UTRAN. 

The UE Core Network Capability contains non radio-related capabilities, e.g. the NAS security algorithms etc. The UE 
Core Network Capability has the same format and content as the MS Network Capability specified in TS 24.008 [47]. 
The UE Core Network Capability is transferred between CN nodes at MME to MME, MME to SGSN, SGSN to SGSN, 
and SGSN to MME changes. 

In order to ensure that the UE Core Network Capability information stored in the MME is up to date (e.g. to handle the 
situation when the USIM is moved into a different device while out of coverage, and the old device did not send the 
Detach message; and the cases of inter-RAT Tracking Area Update), the UE shall send the UE Core Network 
Capability information to the MME during the Attach and non-periodic Tracking Area Update procedure within the 
NAS message. 

The MME shall store always the latest UE Core Network Capability received from the UE. Any UE Core Network 
Capability that an MME receives from an old MME/SGSN is replaced when the UE provides the UE Core Network 
Capability with the Tracking Area Update signalling. 

In order to ensure that the UE Radio Capability information stored in the MME is up to date (e.g. to handle the situation 
when the USIM is moved into a different device while out of coverage, and the old device did not send the Detach 
message), the MME shall delete any stored UE Radio Capability everytime the UE performs the Attach procedure. In 
the Attach procedure the MME shall not send any UE Radio Capability information in the S 1 interface INITIAL 
CONTEXT SETUP REQUEST message. This triggers the E-UTRAN to request the UE Radio Capability from the UE 
and upload them to the MME in the UE CAPABILITY INFO INDICATION message. 

The UE Radio Capability is not transferred between CN nodes. It will be uploaded to the MME when the E-UTRAN 
requests the UE Radio Capability information from the UE. 

During handover via the MME (both intra RAT and inter RAT), the UE Radio Capability is transferred in the "source to 
target transparent container" and uploaded from eNB to the MME. 

To allow for the addition of future radio technologies, frequency bands, and other enhancements, the MME shall store 
the UE Capability Information even if it is larger than specified in TS 24.301 [46], up to a maximum size of [255] 
octets. 

NOTE 2: The 255 octet value comes from the information element encoding rules described in TS 24.007 [45] and 
the assumption that this UE Radio Capability Information has to be signalled in GERAN NAS signalling 
for the case of GERAN to E-UTRAN PS handover. 
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The E-UTRAN stores the UE Radio CapabiHty information, received in the SI interface INITIAL CONTEXT SETUP 
REQUEST message or obtained from the UE, for the duration of the RRC connection for that UE. 

If the UE's UE Core Network CapabiHty information changes (in either ECM-CONNECTED or in ECM-IDLE state 
(including cases of being in GERANAJTRAN coverage and having ISR active)), the UE shall perform a Tracking Area 
Update ('type' different to 'periodic') when it next returns to E-UTRAN coverage. 
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Annex A: 
Void 
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Annex B: 
Void 
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Annex C: 
Void 
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Annex D (normative): 
Interoperation with Gn/Gp SGSNs 

D.1 General Considerations 

This annex specifies interworking between the EPS and 3 GPP 2G and/or 3G SGSNs, which provide only Gn and Gp 
interfaces but no S3, S4 or S5/S8 interfaces interfaces, i.e. these Gn/Gp SGSNs provide no functionaUty that is 
introduced specifically for the EPS or for interoperation with the E-UTRAN. 

Interoperation scenarios for operating E-UTRAN with a PLMN maintaining Gn/Gp SGSNs are supported only with a 
GTP-based S5/S8. 

NOTE: PMIP-based S5/S8 may be used, but does not support handovers between the Gn/Gp SGSN and 
MME/SGW. 

The S5/S8 interface for the Operator with Gn/Gp SGSNs will be GTP-based, but can be changed to PMIP-based S5/S8 
when the Gn/Gp SGSNs evolve to S4 SGSNs. 

For these interoperation scenarios the GERAN/UTRAN has to support interoperation with E-UTRAN. 



D,2 Interoperation Scenario 
D.2.1 Roaming interoperation scenario 

In the roaming scenario the vPLMN operates Gn/Gp 2G and/or 3G SGSNs as well as MME and S-GW for E-UTRAN 
access. The hPLMN operates a P-GW. 

Roaming and inter access mobility between Gn/Gp 2G and/or 3G SGSNs and an MME/S-GW are enabled by: 

- Gn functionality as specified between two Gn/Gp SGSNs, which is provided by the MME, and 

- Gp functionality as specified between Gn/Gp SGSN and Gn/Gp GGSN that is provided by the P-GW. 
All this Gp and Gn functionality bases on GTP version 1 only. 

The architecture for interoperation with Gn/Gp SGSNs in the non-roaming case is illustrated in Figure D.2.1-1. 
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Figure D.2.1-1 : Roaming architecture for interoperation with Gn/Gp SGSN 
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D.2.2 Non-roaming interoperation scenario 

In the non-roaming scenario the PLMN operates Gn/Gp 2G and/or 3G SGSNs as well as MME and S-GW for E- 
UTRAN access. 

Intra PLMN roaming and inter access mobility between Gn/Gp 2G and/or 3G SGSNs and an MME/S-GW are enabled 
by: 

- Gn functionality as specified between two Gn/Gp SGSNs, which is provided by the MME, and 

- Gn functionality as specified between Gn/Gp SGSN and Gn/Gp GGSN that is provided by the PGW. 
All this Gn functionality is based on GTP version 1 only. 

The architecture for interoperation with Gn/Gp SGSNs in the non-roaming case is illustrated in Figure D.2.2- 1. 
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Figure D.2.2-1 : Non-roaming Architecture for interoperation with Gn/Gp SGSNs 

NOTE: If the Rel-7 SGSN appHes Direct Tunnel there is a user plane connection between PGW and UTRAN. 



D,3 Interoperation procedures 
D.3.1 General 

The interoperation procedures describe information flows for Gn/Gp SGSNs and other EPS network elements. All 
messages between SGSN and MME, between SGSN and HSS and between SGSN and P-GW as well as the therein 
contained information elements are the same as specified for the adequate TS 23.060 [7] procedures. These messages 
and procedure step descriptions are taken from TS 23.060 [7] for explanatory purposes only. These descriptions are in 
italic text and shall not be modified by the interoperation procedures. It cannot be assumed that the messages and 
procedure step descriptions that are taken from TS 23.060 [7] will be updated when modifications or corrections are 
performed for TS 23.060 [7]. If there are any discrepancies for these messages and procedure step descriptions 
TS 23.060 [7] takes precedence. The messages between the MME and any other node than the Gn/Gp SGSN as well as 
the therein contained information elements are the same as specified in the main body of this technical specification for 
the inter RAT Routeing Area Update procedure. If there are any discrepancies for these messages the descriptions from 
the main body of this Technical Specification take precedence. 

An operator that has pre-Rel-8 SGSNs in its network should use separate EPS bearers for IPv4 and IPv6 adressing, such 
that both addresses can be maintained when moving to a pre-Rel-8 SGSN from a Rel-8 SGSN or MME (see 
clause 5.3.1). This is configured into the SGSN and MME nodes which set the Dual Address Bearer Flag depending on 
whether a UE may or may not be handed over to a pre-Rel-8 SGSN, as specified in clauses 5.3.2.1 and 5.10.2. 
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D.3.3 MME to 3G SGSN combined hard handover and SRNS 
relocation procedure 

The MME to 3G SGSN Combined Hard Handover and SRNS Relocation procedure is illustrated in Figure D.3.3-1. 

Any steps descriptions that are from TS 23.060 [7] are shown as italic text and remain unmodified. In those step 
descriptions an MS stands for UE, old SGSN for old MME and GGSN for PGW. 

The same procedure applies for S4 SGSN to Gn/Gp SGSN Combined Hard Handover and SRNS Relocation procedure. 
In this case the old MME is an old S4 SGSN. 

The proced ure between E-UTRAN eNodeB and UE, and between E-UTRAN eNodeB and MME are copied from 
^^^^1 unmodified. 

Direct forwarding of payload PDUs is assumed in the scenarios below. The indirect forwarding is FES for Gn/Gp 3 GPP 
IRAT handovers. 
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Figure D.3.3-1 : MME to 3G SGSN combined hard handover and SRNS relocation procedure 

1. The source eNodeB decides to initiate a handover to the target access network, UTRAN lu mode. At this point 
both upHnk and downhnk user data is transmitted via the following: Bearer(s) between UE and source eNodeB, 
GTP tunnel(s) between source eNodeB, Serving GW and PDN GW. 



NOTE 1 : This step is unmodified compared to E-UTRAN functionality as described in | 
to MS. 



|. UE corresponds 
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2. The source eNodeB sends a Relocation Required (Cause, Target RNC Identifier, Source eNodeB Identifier, 
Source to Target Transparent Container, Bearers Requesting Data Forwarding List) message to the source MME 
to request the CN to estabHsh resources in the target RNC, target SGSN and the Serving GW. 

Bearers Requesting Data Forwarding List contains that Hst of bearers for which the source eNodeB decided that 
data forwarding (direct) is necessary. 

NOTE 2: The possibiHty for indirect forwarding of pay load PDUs is omitted in the step above. Otherwise the step 
is unmodified compared to E-UTRAN functionality as described in 

3. The old MME sends a Forward Relocation Request message (IMSI, Tunnel Endpoint Identifier Signalling, MM 
Context, PDP Context, Target Identification, RAN Transparent Container, RANAP Cause, GCSI) to the new 
SGSN. For relocation to an area where Intra Domain Connection of RAN Nodes to Multiple CN Nodes is used, 
the old MME may have multiple new SGSNs for each relocation target in a pool area, in which case the old 
MME will select one of them to become the new SGSN, as specified in TS 23.236 [30]. PDP context contains 
GGSN Address for User Plane and Uplink TEID for Data (to this GGSN Address and Uplink TEID for Data, the 
old SGSN and the new SGSN send uplink packets). At the same time a timer is started on the MM and PDP 
contexts in the old MME (see Routeing Area Update procedure in subclause "Location Management Procedures 
(lu mode)"). The old SGSN 'sets' the GCSI flag if the MM context contains GPRS CAMEL Subscription 
Information. 

NOTE 3: The GGSN user plane address and uplink TEID are the old P-GW user plane address and TEID. The 
MME maps the EPS bearer parameters to PDP contexts. 

4. The new SGSN sends a Relocation Request message (Permanent NAS UE Identity, Cause, CN Domain Indicator, 
Source RNC To Target RNC Transparent Container, RAB To Be Setup) to the target RNC For each RAB 
requested to be established, RABs To Be Setup shall contain information such as RAB ID, RAB parameters. 
Transport Layer Address, and lu Transport Association. SGSN shall not establish RABs for PDP contexts with 
maximum bitratefor uplink and downlink ofO kbit/s. The list of RABs requested by the new SGSN may differ 
from list of RABs established in the Source RNC contained in the Source-RNC to target RNC transparent 
container. The target RNC should not establish the RABs ( as identified from the Source-RNC to target RNC 
transparent container) that did not exist in the source RNC prior to the relocation. The RAB ID information 
element contains the NSAPI value, and the RAB parameters information element gives the QoS profile. The 
Transport Layer Address is the SGSN Address for user data, and the lu Transport Association corresponds to 
the uplink Tunnel Endpoint Identifier Data. The new SGSN may decide to establish Direct Tunnel unless it has 
received a 'set' GCSI flag from the old SGSN. If the new SGSN decides to establish Direct Tunnel, it provides to 
the target RNC the GGSN's Address for User Plane and TEID for Uplink data. 

After all the necessary resources for accepted RABs including the lu user plane are successfully allocated, the 
target RNC shall send the Relocation Request Acknowledge message (Target RNC To Source RNC Transparent 
Container, RABs Setup, RABs Failed To Setup) to the new SGSN. Each RAB to be setup is defined by a 
Transport Layer Address, which is the target RNC Address for user data, and the lu Transport Association, 
which corresponds to the downlink Tunnel Endpoint Identifier for user data. The transparent container contains 
all radio-related information that the MS needs for the handover, i.e. a complete RRC message (e.g.. Physical 
Channel Reconfiguration in UTRAN case, or Handover From UTRAN, or Handover Command in GERAN lu 
mode case) to be sent transparently via CN and source SRNC to the MS. For each RAB to be set up, the target 
RNC may receive simultaneously downlink user packets both from the source SRNC and from the new SGSN. 

NOTE 4: This step for the new SGSN is unmodified compared to pre-Rel-8. If the new SGSN decides to establish 
Direct Tunnel, it provides to the target RNC the PGW Address for User Plane and TEID for Uplink data. 
The UE acts as the MS; the old eNodeB acts as the source SRNC. The details of the transparent container 
are FES. 

5. When resources for the transmission of user data between target RNC and new SGSN have been allocated and 
the new SGSN is ready for relocation ofSRNS, the Forward Relocation Response ( Cause, RAN Transparent 
Container, RANAP Cause, Target-RNC Information) message is sent from the new SGSN to the old SGSN. This 
message indicates that the target RNC is ready to receive from source SRNC the forwarded downlink PDUs, i.e., 
the relocation resource allocation procedure is terminated successfully. RAN transparent container and RANAP 
Cause are information from the target RNC to be forwarded to the source SRNC. The Target RNC Information, 
one information element for each RAB to be set up, contains the RNC Tunnel Endpoint Identifier and RNC IP 
address for data forwarding from the source SRNC to the target RNC. The Forward Relocation Response 
message is applicable only in case of inter-SGSN SRNS relocation. 
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NOTE 5: This step is unmodified compared to pre-Rel-8. The old MME acts as the old SGSN, and the source 
eNodeB as the source SRNC. 

6. The source MME completes the preparation phase towards source eNodeB by sending the message Relocation 
Command (Target to Source Transparent Container, Bearers Subject to Data Forwarding List). "Bearers Subject 
to Data forwarding list" may be included in the message and it shall be a list of 'Address(es) and TEID(s) for 
user traffic data forwarding' received from target side in the preparation phase (Step 5). 

The source eNodeB initiates data forwarding for bearers specified in the "Bearers Subject to Data Forwarding 
List". The data forwarding goes directly to target RNC. 



NOTE 6: This step is unmodified compared to E-UTRAN functionality as described in 




7. The source eNodeB initiates data forwarding for bearers specified in the "Bearers Subject to Data Forwarding 
List". The data forwarding may go directly to target RNC or alternatively go via the Serving GW if so decided 
by source MME and or/ target SGSN in the preparation phase. 

NOTE 7: The details of the data forwarding between eNodeB and source SRNC are FES. 

8. The source eNodeB will give a command to the UE to handover to the target access network via the message HO 
from E-UTRAN Command. This message includes a transparent container including radio aspect parameters that 
the target RNC has set-up in the preparation phase. The details of this E-UTRAN specific signalling are 
described in TS 36.300 [5]. 



NOTE 8: This step is unmodified compared to E-UTRAN functionality as described in 




9. The source SRNC continues the execution of relocation ofSRNS by sending a Forward SRNS Context (RAB 
Contexts) message to the target RNC via the old and the new SGSN The Forward SRNS Context message is 
acknowledged by a Forward SRNS Context Acknowledge message, from new to old SGSN The purpose of this 
procedure is to transfer SRNS contexts from the source RNC to the target RNC, and to move the SRNS role from 
the source RNC to the target RNC SRNS contexts are sent for each concerned RAB and contain the sequence 
numbers of the GTP PDUs next to be transmitted in the uplink and downlink directions and the next PDCP 
sequence numbers that would have been used to send and receive data from the MS. PDCP sequence numbers 
are only sent by the source RNC for the radio bearers which used lossless PDCP [57]. The use of lossless PDCP 
is selected by the RNC when the radio bearer is set up or reconfigured. For PDP context(s) using delivery order 
not required (QoS profile), the sequence numbers of the GTP-PDUs next to be transmitted are not used by the 
target RNC. 

If delivery order is required (QoS profile), consecutive GTP-PDU sequence numbering shall be maintained 
throughout the lifetime of the PDP context(s). Therefore, during the entire SRNS relocation procedure for the 
PDP context(s) using delivery order required (QoS profile), the responsible GTP-U entities (RNCs and GGSN) 
shall assign consecutive GTP-PDU sequence numbers to user packets belonging to the same PDP context uplink 
and downlink, respectively. 

The target RNC establishes and/or restarts the RLC and exchanges the PDCP sequence numbers (PDCP-SNU, 
PDCP-SND) between the target RNC and the MS. PDCP-SND is the PDCP sequence number for the next 
expected in-sequence downlink packet to be received by the MS per radio bearer, which used lossless PDCP in 
the source RNC. PDCP-SND confirms all mobile terminated packets successfully transferred before the SRNC 
relocation. If PDCP-SND confirms reception of packets that were forwarded from the source SRNC, then the 
target SRNC shall discard these packets. PDCP-SNU is the PDCP sequence number for the next expected in- 
sequence uplink packet to be received in the RNC per radio bearer, which used lossless PDCP in the source 
RNC. PDCP-SNU confirms all mobile originated packets successfully transferred before the SRNC relocation. If 
PDCP-SNU confirms reception of packets that were received in the source SRNC, the MS shall discard these 
packets. 

NOTE 9: This step is unmodified compared to pre-Rel-8. The old MME acts as the old SGSN, and the source 

eNodeB as t he source S RNC. The forward SRNS Context message from source eNodeB to the old MME 
is defined in The UE acts as the MS. The whole SRNS context handling including PDCP 

sequence number handling and GTP numbering is FES. 

10. The target RNC shall send a Relocation Detect message to the new SGSN when the relocation execution trigger 
is received. For SRNS relocation type "UE Involved", the relocation execution trigger may be received from the 
Uu interface; i.e., when target RNC detects the MS on the lower layers. When the Relocation Detect message is 
sent, the target RNC shall start SRNC operation. 
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NOTE 10: This step is unmodified compared to pre-Rel-8. 

11. When the target SRNC receives the appropriate RRC message, e.g. Physical Channel Reconfiguration Complete 
message or the Radio Bearer Release Complete message in UTRAN case, or the Handover To UTRAN Complete 
message or Handover Complete message in GERAN case, i.e. the new SRNC-ID + S-RNTI are successfully 
exchanged with the MS by the radio protocols, the target SRNC shall initiate a Relocation Complete procedure 
by sending the Relocation Complete message to the new SGSN. The purpose of the Relocation Complete 
procedure is to indicate by the target SRNC the completion of the relocation of the SRNS to the CN. 

NOTE ll:This step is unmodified compared to pre-Rel-8. The UE acts as the MS. 

12. Upon receipt of Relocation Complete message, if the SRNS Relocation is an inter SGSN SRNS relocation, the 
new SGSN signals to the old SGSN the completion of the SRNS relocation procedure by sending a Forward 
Relocation Complete message. 

A timer in source MME is started to supervise when resources in Source eNodeB and Source Serving GW shall 
be released. 

NOTE 12:For the SGSN this step is unmodified compared to pre-Rel-8. The old MME acts as the old SGSN, and 
the source eNodeB as the source SRNC. 

13. Upon receipt of the Relocation Complete message, the CN shall switch the user plane from the source RNC to 
the target SRNC. If the SRNS Relocation is an inter-SGSN SRNS relocation or if Direct Tunnel was established 
in intra-SGSN SRNS relocation, the new SGSN sends Update PDF Context Request messages (new SGSN 
Address, SGSN Tunnel Endpoint Identifier, QoS Negotiated, serving network identity, CGI/SAI, RAT type, 
CGI/SAI/RAI change support indication, NRSN, DTI) to the GGSNs concerned. The SGSN shall send the serving 
network identity to the GGSN If Direct Tunnel is established the SGSN provides to GGSN the RNC 's Address for 
User Plane and TEIDfor Downlink data and shall include the DTI to instruct the GGSN to apply Direct Tunnel 
specific error handling procedure as described in clause 13.8. NRSN indicates SGSN support of the network 
requested bearer control. The GGSNs update their PDP context fields and return an Update PDP Context 
Response ( GGSN Tunnel Endpoint Identifier, Prohibit Payload Compression, APN Restriction, CGI/SAI/RAI 
change report required, BCM) message. The Prohibit Payload Compression indicates that the SGSN should 
negotiate no data compression for this PDP context. 

NOTE 13: This step is unmodified compared to pre-Rel-8. The P-GW acts as the GGSN. 

14. When the timer started at Step 12 expires, the source MME sends a Release Resources message to the source 
eNodeB. When the Release Resources message has been received and there is no longer any need for the 
eNodeB to forward data, the Source eNodeB releases its resources. 

NOTE 14: This step is unmodified compared to E-UTRAN functionality as described in ^^^^1. 

15. After the MS has finished the reconfiguration procedure and if the new Routeing Area Identification is different 
from the old one, the MS initiates the Routeing Area Update procedure. See subclause "Location Management 
Procedures (lu mode)". Note that it is only a subset of the RA update procedure that is performed, since the MS 
is in PMM-CONNECTED state. 

NOTE 15: This step is unmodified compared to pre-Rel-8. The UE acts as the MS. The old EPS bearer information 
in Serving GW is removed as part of the Routeing Area Update procedure. 

16. When the timer started in step 12 expires, the source MME deletes the EPS bearer resources by sending Delete 
Bearer Request (Cause, TEID) messages to the Source Serving GW because the old SGSN is a Gn/Gp SGSN, 
which is derived from relocation signalling between SGSN and MME. Cause indicates to the old Serving GW 
that the Serving GW changes and the old Serving GW shall not initiate a delete procedure towards the PDN GW. 
The Source Serving GW acknowledges with Delete Bearer Response (TEID) messages. IflSR is established on 
the S-GW then the S-GW deletes the bearer resources on the other old CN node by sending Delete Bearer 
Request message(s) to that CN node. 

If the SRNS Relocation is inter-SGSN, then the following CAMEL procedure calls shall be performed (see referenced 
procedures in TS 23.078 [29]) 

NOTE 16: The CI CAMEL procedure call was omitted intentionally from this procedure since EPS does not support 
CAMEL procedure calls. The other CAMEL procedure calls are unmodified compared to pre-Rel-8. 
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The new SGSN shall determine the Maximum APN restriction based on the received APN Restriction of each PDF 
context from the GGSN and then store the new Maximum APN restriction value. 

If the SRNS Relocation is intra-SGSN, then the above mentioned CAMEL procedures calls shall not be performed. 

IfRouteing Area Update occurs, the SGSN shall determine whether Direct Tunnel can be used based on the received 
GPRS CAMEL Subscription Information. If Direct Tunnel can not be maintained the SGSN shall re-establish RABs and 
initiate the Update PDP Context procedure to update the IP Address and TEIDfor Uplink and Downlink data. 

If Routeing Area Update occurs, then the following CAMEL procedure calls shall be performed (see referenced 
procedures in TS 23.078 [29]): 

C2) CAMEL_GPRS_Routeing_Area_Update_Session and CAMEL_PS_Notification. 

They are called in the following order: 

The CAMEL_GPRS_Routeing_Area_Update_Session procedure is called. In Figure 42, the procedure 
returns as result ''Continue ". 

Then the CAMEL_PS_Notification procedure is called. The procedure returns as result "Continue ". 
C3 ) CAMEL_GPRS_Routeing_Area_Update_Context. 
This procedure is called several times: once per PDP context. It returns as result "Continue ". 
For C2 and C3: refer to Routing Area Update procedure description for detailed message flow. 



D.3.4 3G SGSN to MME combined hard handover and SRNS 
relocation procedure 

The 3G SGSN to MME Combined Hard Handover and SRNS Relocation procedure is illustrated in Figure D.3.4-1. 

Any steps descriptions that are from TS 23.060 [7] are shown as italic text and remain unmodified. In those step 
descriptions an MS stands for UE, new SGSN for new MME and GGSN for PGW. 

The same procedure applies for Gn/Gp SGSN to S4 SGSN Combined Hard Handover and SRNS Relocation procedure. 
In this case the new MME is a new Rel-8 SGSN. 

The procedure between E-UTRAN eNodeB and UE, and between E-UTRAN eNodeB and MME are copied from 
^^^^^1 unmodified. 

Direct forwarding of payload PDUs is assumed in the scenarios below. The indirect forwarding is FES for 3GPP IRAT 
handovers with Gn/Gp SGSNs. 
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Figure D.3.4-1 : 3G SGSN to MME combined hard handover and SRNS relocation procedure 

1 . The source RNC decides to initiate a handover to E-UTRAN. 

2. The source SRNC sends a Relocation Required message (Relocation Type, Cause, Source ID, Target ID, Source 
RNC To Target RNC Transparent Container) to the old SGSN The source SRNC shall set Relocation Type to 
"UE Involved". Source RNC To Target RNC Transparent Container includes the necessary information for 
relocation co-ordination, security functionality and RRC protocol context information (including MS 
Capabilities). 

NOTE 1: This step is unmodified compared to pre-Rel-8. The target eNodeB acts as the target RNC. 

3. The old SGSN determines from the Target ID if the SRNS relocation is intra-SGSN SRNS relocation or inter- 
SGSN SRNS relocation. In case of inter- SGSN SRNS relocation the old SGSN initiates the relocation resource 
allocation procedure by sending a Forward Relocation Request message (IMSI, Tunnel Endpoint Identifier 
Signalling, MM Context, PDF Context, Target Identification, RAN Transparent Container, RANAP Cause, 
GCSI) to the new SGSN. For relocation to an area where Intra Domain Connection of RAN Nodes to Multiple 
CN Nodes is used, the old SGSN may - if it provides Intra Domain Connection of RAN Nodes to Multiple CN 
Nodes -have multiple target SGSNsfor each relocation target in a pool area, in which case the old SGSN will 
select one of them to become the new SGSN, as specified in TS 23.236 [30]. PDF context contains GGSN 
Address for User Plane and Uplink TEID for Data (to this GGSN Address and Uplink TEID for Data, the old 
SGSN and the new SGSN send uplink packets). At the same time a timer is started on the MM and PDF contexts 
in the old SGSN (see Routeing Area Update procedure in subclause "Location Management Procedures (lu 
mode)"). The Forward Relocation Request message is applicable only in case of inter-SGSN SRNS relocation. 
The old SGSN 'sets' the GCSI flag if the MM context contains GPRS CAMEL Subscription Information. 
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NOTE 2: This step is unmodified compared to pre-Rel-8. The new MME acts the new SGSN, and the PGW as the 
GGSN. The GGSN user plane address and upHnk TEID are the PGW user plane address and TEID. The 
MME maps the PDF context parameters to EPS bearers. 

4. The MME selects a Serving GW and sends a Create Bearer Request (bearer context(s) with PDN GW addresses 
and TEIDs for uplink traffic, local AMBR) message to the target Serving GW. The AMBR is locally provided 
by the target MME. 

5. The Serving GW allocates the S-GW addresses and TEIDs for the uplink traffic on S1_U reference point (one 
TEID per bearer). The target Serving GW sends a Create Bearer Response (Serving GW addresses and uplink 
TEID(s) for user plane) message back to the target MME. 

6. The target MME requests the target eNodeB to establish the bearer(s) by sending the message Relocation 
Request (UE Identifier, Cause, CN Domain Indicator, K_eNB, Integrity protection information (i.e. selected 
Integrity Protection algorithm(s)). Encryption information (i.e. selected Ciphering algorithm(s)), EPS Bearers to 
be setup list. Source to Target Transparent Container, Serving GW Address(es) and TEID(s) for User Traffic 
Data, KSI, key derivation parameter). 

If the MME has a security association with the UE, the earlier selected NAS and AS security algorithms and 
related keys will be utilized on handover to E-UTRAN. If the MME does not have a security association with the 
UE, then an operator configured default security algorithm is applied for NAS and AS (UP and RRC) security. 
KSI and key derivation parameters are targeted for UE. The KSI parameter informs the UE whether a security 
association exists with the MME and is used or whether it does not exist and UTRAN CK and IK based keys are 
used in target eNB and in the target MME. 

The local AMBR shall be included in the 'EPS Bearers be setup list ' IE when AMBR is needed. 

NOTE 3: This step is unmodified compared to The MME derives the security parameters from the 

security parameters received from the SGSN. 

7. The target eNodeB allocates the requested resources and returns the applicable parameters to the target MME in 
the message Relocation Request Acknowledge (Target to Source Transparent Container, EPS Bearers setup list, 
EPS Bearers failed to setup list). 

In addition to the information provided by the MME (KSI, key derivation parameter), the target eNodeB inserts 
eNB C-RNTI that is used to derive target eNB KeNB as well as the RRC and UP keys into the UTRAN RRC 
message, which is contained in the Target to Source Transparent Container. 



NOTE 4: This step is unmodified compared to 




8. When resources for the transmission of user data between target RNC and new SGSN have been allocated and 
the new SGSN is ready for relocation ofSRNS, the Forward Relocation Response (Cause, RAN Transparent 
Container, RANAP Cause, Tar get-RNC Information) message is sent from the new SGSN to the old SGSN This 
message indicates that the target RNC is ready to receive from source SRNC the forwarded downlink PDUs, i.e., 
the relocation resource allocation procedure is terminated successfully. RAN transparent container and RANAP 
Cause are information from the target RNC to be forwarded to the source SRNC. The Target RNC Information, 
one information element for each RAB to be set up, contains the RNC Tunnel Endpoint Identifier and RNC IP 
address for data forwarding from the source SRNC to the target RNC. The Forward Relocation Response 
message is applicable only in case of inter-SGSN SRNS relocation. 

NOTE 5: This step is unmodified compared to pre-Rel-8. The new MME acts as the new SGSN, and the target 
eNodeB as the target SRNC. 

9. The old SGSN continues the relocation of SRNS by sending a Relocation Command message (Target RNC To 
Source RNC Transparent Container, RABs To Be Released, RABs Subject To Data Forwarding) to the source 
SRNC. The old SGSN decides the RABs to be subject for data forwarding based on QoS, and those RABs shall be 
contained in RABs subject to data forwarding. For each RAB subject to data forwarding, the information 
element shall contain RAB ID, Transport Layer Address, and lu Transport Association. These are the same 
Transport Layer Address and lu Transport Association that the target RNC had sent to new SGSN in Relocation 
Request Acknowledge message, and these are used for forwarding of downlink N-PDU from the source SRNC to 
the target RNC. The source SRNC is now ready to forward downlink user data directly to the target RNC over 
the lu interface. This forwarding is performed for downlink user data only. 
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NOTE 6: This step is unmodified compared to pre-Rel-8. The target eNodeB acts as the target RNC, and the new 
MME acts as the new SGSN. Note: The details of the data forwarding between eNodeB and source 
SRNC are FFS. 

10. The source SRNC may, according to the QoS profile, begins the forwarding of data for the RABs to be subject 
for data forwarding. 

NOTE 7: The order of steps, starting from step 7 onwards, does not necessarily reflect the order of events. For 
instance, source RNC may start data forwarding (step 7), send the RRC message to MS (step 8) and 
forward SRNS Context message to the old SGSN (step 9) almost simultaneously. 

The data forwarding at SRNS relocation shall be carried out through the lu interface, meaning that the GTP- 
PDUs exchanged between the source SRNC and the target RNC are duplicated in the source SRNC and routed 
at the IP layer towards the target RNC. For each radio bearer which uses lossless PDCP the GTP-PDUs related 
to transmitted but not yet acknowledged PDCP-PDUs are duplicated and routed at IP layer towards the target 
RNC together with their related downlink PDCP sequence numbers. The source RNC continues transmitting 
duplicates of downlink data and receiving uplink data. 

Before the serving RNC role is not yet taken over by target RNC and when downlink user plane data starts to 
arrive to target RNC, the target RNC may buffer or discard arriving downlink GTP-PDUs according to the 
related QoS profile. 

NOTE 8: This step is unmodified compared to pre-Rel-8. The new MME acts as the new SGSN, and the target 
eNodeB as the target SRNC. The data forwarding may go directly to target eNodeB or alternatively go 
via the Serving GW if so decided by new MME and or/ old SGSN in the preparation phase. The details of 
the data forwarding between eNodeB and source SRNC are FFS. 

11. Before sending the RRC message the uplink and downlink data transfer shall be suspended in the source SRNC 
for RABs, which require delivery order. The RRC message is for example Physical Channel Reconfiguration for 
RNS to RNS relocation, or Intersystem to UTRAN Handover for BSS to RNS relocation, or Handover from 
UTRAN Command for BSS relocation, or Handover Command for BSS to BSS relocation. When the source 
SRNC is ready, the source RNC shall trigger the execution of relocation of SRNS by sending to the MS the RRC 
message provided in the Target RNC to source RNC transparent container, e.g., a Physical Channel 
Reconfiguration (UE Information Elements, CN Information Elements) message. UE Information Elements 
include among others new SRNC identity and S-RNTI. CN Information Elements contain among others Location 
Area Identification and Routeing Area Identification. 

When the MS has reconfigured itself, it sends an RRC message e.g., a Physical Channel Reconfiguration 
Complete message to the target SRNC. If the Forward SRNS Context message with the sequence numbers is 
received, the exchange of packets with the MS may start. If this message is not yet received, the target RNC may 
start the packet transfer for all RABs, which do not require maintaining the delivery order. 

NOTE 9: This step is unmodified compared to pre-Rel-8. This text is valid for the RRC message sent from source 
RNC to the UE. When the UE has got access to target eNodeB it sends the HO to E-UTRAN Complete 
message. This RRC message received as part of Target to Source Transparent Container, includes 
information about the selected security algorithms and related key information. Based on this information, 
the UE selects the same algorithms for the NAS in case the KSI value indicates that the MME has no 
security association with the UE. In case the KSI value indicates that the MME has a security association 
with the UE, but the UE has lost the security context of the E-UTRAN side (error case), the UE will start 
Attach procedure on the E-UTRAN side 

12. The source SRNC continues the execution of relocation of SRNS by sending a Forward SRNS Context (RAB 
Contexts) message to the target RNC via the old and the new SGSN. The Forward SRNS Context message is 
acknowledged by a Forward SRNS Context Acknowledge message, from new to old SGSN. The purpose of this 
procedure is to transfer SRNS contexts from the source RNC to the target RNC, and to move the SRNS role from 
the source RNC to the target RNC. SRNS contexts are sent for each concerned RAB and contain the sequence 
numbers of the GTP PDUs next to be transmitted in the uplink and downlink directions and the next PDCP 
sequence numbers that would have been used to send and receive data from the MS. PDCP sequence numbers 
are only sent by the source RNC for the radio bearers which used lossless PDCP [57]. The use of lossless PDCP 
is selected by the RNC when the radio bearer is set up or reconfigured. For PDP context(s) using delivery order 
not required ( QoS profile), the sequence numbers of the GTP-PDUs next to be transmitted are not used by the 
target RNC. 
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If delivery order is required (QoS profile), consecutive GTP-PDU sequence numbering shall be maintained 
throughout the lifetime of the PDF context(s). Therefore, during the entire SRNS relocation procedure for the 
PDF context(s) using delivery order required (QoS profile), the responsible GTP-U entities (RNCs and GGSN) 
shall assign consecutive GTP-PDU sequence numbers to user packets belonging to the same PDP context uplink 
and downlink, respectively. 

The target RNC establishes and/or restarts the RLC and exchanges the PDCP sequence numbers (PDCP-SNU, 
PDCP-SND) between the target RNC and the MS. PDCP-SND is the PDCP sequence number for the next 
expected in-sequence downlink packet to be received by the MS per radio bearer, which used lossless PDCP in 
the source RNC. PDCP-SND confirms all mobile terminated packets successfully transferred before the SRNC 
relocation. If PDCP-SND confirms reception of packets that were forwarded from the source SRNC, then the 
target SRNC shall discard these packets. PDCP-SNU is the PDCP sequence number for the next expected in- 
sequence uplink packet to be received in the RNC per radio bearer, which used lossless PDCP in the source 
RNC. PDCP-SNU confirms all mobile originated packets successfully transferred before the SRNC relocation. If 
PDCP-SNU confirms reception of packets that were received in the source SRNC, the MS shall discard these 
packets. 

NOTE 10: This step is unmodified compared to pre-Rel-8. The new MME acts as the new SGSN, and the target 

eNodeB as t he target SR NC. The forward SRNS Context message from new MME to the target eNodeB 
is defined in The whole SRNS context handUng including PDCP sequence number handling 

and GTP numbering is FES. 

13. When the UE has successfully accessed the target eNodeB, the target eNodeB informs the target MME by 
sending the message Relocation Complete. 



NOTE ll:This step is unmodified compared to 




14. Upon receipt of Relocation Complete message, if the SRNS Relocation is an inter SGSN SRNS relocation, the 
new SGSN signals to the old SGSN the completion of the SRNS relocation procedure by sending a Forward 
Relocation Complete message. 

NOTE 12: This step is unmodified compared to pre-Rel-8. The new MME acts as the new SGSN. 

15. The target MME will now complete the PS Handover procedure by informing the Serving GW that the target 
MME is now responsible for all the bearers the UE have established. This is performed in the message Update 
Bearer Request (Cause, Tunnel Endpoint Identifier Control Plane, NSAPI, MME Address for Control Plane, 
eNodeB Address(es) and TEID(s) for User Traffic, RAT type, local AMBR). 



NOTE 13: This step is unmodified compared to 




16. The Serving GW informs the PDN GW the local AMBR and the change of for example the RAT type that e.g. 
can be used for charging, by sending the message Update Bearer Request (local AMBR). The PDN GW must 
acknowledge the request with the message Update Bearer Response. This is FES. 



NOTE 14: This step is unmodified compared to 




17. The Serving GW acknowledges the user plane switch to the target MME via the message Update Bearer 
Response (Cause, Tunnel Endpoint Identifier Control Plane, and Serving GW Address for Control Plane). At this 
stage the user plane path is established for all bearers between the UE, target eNodeB, Serving GW and PDN 
GW. 

NOTE 15: This step is unmodified compared to ^^^^B- 

18. Upon receiving the Relocation Complete message or, if it is an inter-SGSN SRNS relocation, the Forward 
Relocation Complete message, the old SGSN sends an lu Release Command message to the source RNC. When 
the RNC data- forwarding timer has expired, the source RNC responds with an lu Release Complete message. 

NOTE 16: This step is unmodified compared to pre-Rel-8. 

19. The eNB triggers the UE to initiate a Tracking Area Update procedure with the target MME. It is RAN 
functionality to provide the ECM-CONNECTED UE with the trigger information. 

The target MME knows that an IRAT Handover has been performed for this UE as it received the bearer 
context(s) by handover messages and therefore the target MME performs only a subset of the TA update 
procedure, specifically it excludes the context transfer procedures between source SGSN and target MME. 
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20. The MME compares the AMBR from the 'EPS subscribed QoS profile' with the local AMBR it generated. If the 
two AMBRs are different, the MME shall initiate Subscribed QoS Modification procedure to notify the 
subscribed AMBR to the eNodeB, Serving GW and PDN GW. 

If the SRNS Relocation is inter-SGSN, then the following CAMEL procedure calls shall be performed (see referenced 
procedures in TS 23.078 [29]) 

CI ) CAMEL_GPRS_PDP_Context_Disconnection, CAMEL_GPRS_Detach and CAMEL_PS_Notification. 

They are called in the following order: 

- The CAMEL_GPRS_PDP_Context_Disconnection procedure is called several times: once per PDP context. 
The procedure returns as result "Continue". 

Then the CAMEL_GPRS_Detach procedure is called once. The procedure returns as result "Continue". 

- Then the CAMEL_PS_Notification procedure is called once. The procedure returns as result "Continue". 

The new SGSN shall determine the Maximum APN restriction based on the received APN Restriction of each PDP 
context from the GGSN and then store the new Maximum APN restriction value. 

If the SRNS Relocation is intra-SGSN, then the above mentioned CAMEL procedures calls shall not be performed. 

IfRouteing Area Update occurs, the SGSN shall determine whether Direct Tunnel can be used based on the received 
GPRS CAMEL Subscription Information. If Direct Tunnel can not be maintained the SGSN shall re-establish RABs and 
initiate the Update PDP Context procedure to update the IP Address and TEIDfor Uplink and Downlink data. 

If Routeing Area Update occurs, then the following CAMEL procedure calls shall be performed (see referenced 
procedures in TS 23.078 [29]): 

NOTE 17: This CAMEL handling is unmodified compared to pre-Rel-8. 

NOTE 18: CAMEL procedure calls C2 and C3 were omitted intentionally from this procedure since EPS does not 
support CAMEL procedure calls. 

D.3.5 Routeing Area Update 

The Routeing Area Update procedure takes place when a UE that is registered with an MME or an S4-SGSN selects a 
UTRAN or GERAN cell served by a Gn/Gp SGSN. In this case, the UE changes to a Routeing Area that the UE has not 
yet registered with the network. This procedure is initiated by an idle state or by a connected state UE. The Routeing 
Area Update procedure is illustrated in Figure D.3.5-1. 

Any step descriptions that are taken from TS 23.060 [7] for a Gn/Gp SGSN are shown as italic text and remain 
unmodified. In that step descriptions an MS stands for UE, old SGSN for old MME or old S4-SGSN and GGSN for P- 
GW. The old MME behave towards the new SGSN always like an old Gn/Gp 3G-SGSN, regardless whether the new 
SGSN is a 2G-SGSN or a 3G-SGSN. 
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Figure D.3.5-1 : Routeing Area Update procedure 

0. The UE selects a UTRAN or GERAN cell This cell is in a Routeing Area that is not yet registered with the 
network. The UE in ECM-CONNECTED state may change to the GERAN cell through Network Assisted Cell 
Change (NACC). 

1. The MS sends a Routeing Area Update Request (old P-TMSI, old RAI, old P-TMSI Signature, Update Type, 
follow on request, Classmark, DRX parameters and MS Network Capability, additional P-TMSI/RAI) to the new 
SGSN. Update Type shall indicate RA update, periodic RA update. Combined RA / LA Update or Combined 
RA / LA Update with IMSI attach requested. The BSS shall add the Cell Global Identity including the RAC and 
LAC of the cell where the message was received before passing the message to the SGSN. The SRNC shall add 
the Routeing Area Identity before forwarding the message to the 3G-SGSN. Classmark contains the MS GPRS 
multislot capabilities and supported GPRS ciphering algorithms as defined in TS 24.008 [47]. DRX Parameters 
indicates whether or not the MS uses discontinuous reception and the DRX cycle length. The SGSN may use, as 
an implementation option, the follow-on request indication to release or keep the lu connection after the 
completion of the RA update procedure. 
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If the UE's TIN indicates "GUTI" and the UE holds a vaUd GUTI then the UE indicates the GUTI as the old 
P-TMSI and old RAI. If the UE's TIN indicates "P-TMSI" or "RAT-related TMSI" and the UE holds a vaHd 
P-TMSI and related RAI then these two elements are indicated as old P-TMSI and old RAI. Mapping a GUTI to 
a P-TMSI and an RAI is specified in Annex H. 

If the UE holds a valid P-TMSI and related RAI then the UE indicates these parameters as additional 
P-TMSI/RAI, regardless whether the old P-TMSI and old RAI indicate the same parameters or parameters 
mapped from a GUTI. 

The old P-TMSI is indicated in the RAU Request message for lu-mode only. For Gb mode the TLLI is derived 
from the value that is determined as the old P-TMSI according to the rules above. The routing parameter that is 
signalled in the RRC signalling to the RNC for routing to the SGSN is derived from the identifier that is 
signalled as the old P-TMSI according to the rules above. For a combined MME/SGSN the RAN is configured to 
route the NRI(s) of this combined node to the same combined node. The RAN is also configured to route NRI(s) 
of P-TMSIs that are generated by the UE's mapping of the GUTIs allocated by the combined node. Such a RAN 
configuration may also be used for separate nodes to avoid changing nodes in the pool caused by inter RAT 
mobility. 



NOTE 1: This step is unmodified for an SGSN compared to pre-Rel-8. 

2. The new SGSN sends SGSN Context Request (old RAI, TLLI or old P-TMSI, old P-TMSI Signature, New SGSN 
Address) to the old SGSN to get the MM and PDP contexts for the MS. If the new SGSN provides functionality 
for Intra Domain Connection of RAN Nodes to Multiple CN Nodes, the new SGSN may derive the old SGSN from 
the old RAI and the old P-TMSI (or TLLI) and send the SGSN Context Request message to this old SGSN 
Otherwise, the new SGSN derives the old SGSN from the old RAI. In any case the new SGSN will derive an 
SGSN that it believes is the old SGSN. This derived SGSN is itself the old SGSN, or it is associated with the same 
pool area as the actual old SGSN and it will determine the correct old SGSN from the P-TMSI (or TLLI) and 
relay the message to that actual old SGSN. 

NOTE 2: A GUTI mapped to a P-TMSI/RAI provides an old RAI that uniquely identifies an old MME then there is 
no need to relay between MME in the old pool, regardless whether the new SGSN supports such functionality or 
not. Mapping a GUTI to a P-TMSI and an RAI is specified in Annex H. 

The old SGSN validates the old P-TMSI Signature and responds with an appropriate error cause if it does not 
match the value stored in the old SGSN. This should initiate the security functions in the new SGSN. If the 
security functions authenticate the MS correctly, the new SGSN shall send an SGSN Context Request (old RAI, 
TLLI, MS Validated, New SGSN Address) message to the old SGSN. MS Validated indicates that the new SGSN 
has authenticated the MS. If the old P-TMSI Signature was valid or if the new SGSN indicates that it has 
authenticated the MS, the old SGSN starts a timer. If the MS is not known in the old SGSN, the old SGSN 
responds with an appropriate error cause. 

NOTE 3: For the new SGSN, this step is unmodified compared to pre-Rel-8. The MME (called old SGSN in above 
description) needs to provide SGSN functionality. 

2b. The old 3G SGSN responds with an SGSN Context Response (MM Context, PDP Contexts) message. For each 
PDP context the old 3G-SGSN shall include the GTP sequence number for the next uplink GTP PDU to be 
tunnelled to the GGSN and the next downlink GTP sequence number for the next PDU to be sent to the MS. Each 
PDP Context also includes the PDCP sequence numbers ifPDCP sequence numbers are received from the old 
SRNS. The new 3G-SGSN shall ignore the MS Network Capability contained in MM Context of SGSN Context 
Response only when it has previously received an MS Network Capability in the Routeing Area Request. The 
GTP sequence numbers received from the old 3G-SGSN are only relevant if delivery order is required for the 
PDP context ( QoS profile). 

NOTE 4: This step is for the Gn/Gp SGSN unmodified compared to pre-Rel-8. The MME or old S4-SGSN (old 
SGSN in this step) needs to map EPS bearer information to PDP contexts; this mapping is FES. The Gn 
signalling between the new Gn/Gp SGSN and the old CN node has no capabilities to indicate ISR. 

FES whether and how to perform any data forwarding from eNodeB or S-GW to the SGSN. 

3. Security functions may be executed. These procedures are defined in clause "Security Function" in 

TS 23.060 [7]. Ciphering mode shall be set if ciphering is supported. If the SGSN Context Response message did 
not include IMEISV and ADD is supported by the SGSN, the SGSN retrieves the IMEISV from the MS. 
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If the security functions fail (e.g. because the SGSN cannot determine the HLR address to establish the Send 
Authentication Info dialogue), the Inter SGSN RAU Update procedure fails. A reject shall be returned to the MS 
with an appropriate cause. 

NOTE 5: This step is unmodified compared to pre-Rel-8. 

4. The new SGSN sends an SGSN Context Acknowledge message to the old SGSN. The old MME (which is the old 
SGSN from the new SGSN's point of view) marks in its context that the information in the GWs and the HSS are 
invalid. This triggers the GWs, and the HSS to be updated if the UE initiates a Tracking Area Update procedure 
back to the old MME before completing the ongoing Routeing Area Update procedure. If the security functions 
do not authenticate the MS correctly, then the routeing area update shall be rejected, and the new SGSN shall 
send a reject indication to the old SGSN. The old MME shall continue as if the SGSN Context Request was 
never received. 

NOTE 6: The new SGSN's operation is unmodified compared to pre-Rel-8. The handling within the MME may 

need further alignment with the Rel-8 inter RAT RAU, e.g. FES whether this informs the old MME that 
the new SGSN is ready to receive data packets belonging to the activated PDP contexts and how to 
perform any data forwarding from eNodeB or S-GW to the SGSN. 

4a. If the SI user plane is established for the UE the old MME sends a Data Forward Command (Bearer ID, 
Transport Layer Address, SI Transport Association) message to the eNodeB. 

NOTE 7: This step describes pre-Rel-8 SGSN and RNC behaviour to be executed by the MME and eNodeB. 
Further evaluations needed, e.g. Data forwarding is FFS. 

5. For each indicated Bearer ID the old eNodeB duplicates the buffered N-PDUs and starts tunnelling them to the 
new SGSN. For each Bearer ID which uses lossless PDCP the eNodeB shall start tunnelling the GTP-PDUs 
related to transmitted but not yet acknowledged PDCP-PDUs to the new SGSN together with their related 
downlink PDCP sequence numbers. Additional N-PDUs received from the SGW before the timer described in 
step 2 expires are also duplicated and tunnelled to the new SGSN. No N-PDUs shall be forwarded to the new 
SGSN after expiry of the timer described in step 2. 

The conversion of PDCP sequence numbers to SNDCP sequence numbers (the eight most significant bits shall 
be stripped off) is done by the new SGSN as defined in Rel-7 for GTPvl. This implies also that no N-PDU 
sequence numbers shall be indicated for these N-PDUs. GTPvO at the SGSN would require a conversion by the 
SGW, which is not supported. 

NOTE 8: This step describes pre-Rel-8 SGSN and RNC behaviour to be executed by the SGW and eNodeB. 
Further evaluations needed, e.g. Data forwarding is FFS. 

6. The new SGSN sends Update PDP Context Request (new SGSN Address, TEID, QoS Negotiated, serving 
network identity, CGI/SAI, RAT type, CGI/SAI/RAI change support indication, NRS) to the GGSNs concerned. 
The SGSN shall send the serving network identity to the GGSN NRS indicates SGSN support of the network 
requested bearer control. The SGSN shall only indicate that it supports the procedure if it supports it and it is 
indicated that the MS also supports it in the SGSN Context Response message as described above. If the NRS is 
not included in the Update PDP Context Request message the GGSN shall, following this procedure, perform a 
GGSN -Initiated PDP Context Modification to change the BCM to 'MS-Only' for all PDP -Address/APN -pairs for 
which the current BCM is 'NWjOnly'. The GGSNs update their PDP context fields and return Update PDP 
Context Response (TEID, Prohibit Pay load Compression, APN Restriction, CGI/SAI/RAI change report 
required). The Prohibit Pay load Compression indicates that the SGSN should negotiate no data compression for 
this PDP context. 

NOTE 9: This step is unmodified compared to pre-Rel-8. 

7. The new SGSN informs the HLR of the change of SGSN by sending Update Location (SGSN Number, SGSN 
Address, IMSI, IMEISV, Update Type) to the HLR. IMEISV is sent if the ADD function is supported. Update 
Type indicates "normal update". 

NOTE 10: This step is unmodified compared to pre-Rel-8. Clarifiaction about update type added to show that this is 
the trigger for the HSS to cancel only an old SGSN and not also an old MME. 

8. The HLR sends Cancel Location (IMSI, Cancellation Type) to any old SGSN with Cancellation Type set to 
Update Procedure. The old SGSN removes the MM and EPS bearer contexts. The old SGSN acknowledges with 
Cancel Location Ack (IMSI). 
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NOTE lliFor the Gn/Gp SGSN the HSS interoperation is unmodified compared to earlier standards Releases. The 
handling within the MME may need further alignment with the Rel-8 inter RAT RAU, e.g. It is FFS 
whether the old MME or the eNodeB need to complete any forwarding of N-PDUs. 

9. The HLR sends Insert Subscriber Data (IMSI, GPRS Subscription Data) to the new SGSN. The new SGSN 
validates the UE's presence in the (new) RA. If due to regional subscription restrictions or access restrictions the 
MS is not allowed to be attached in the RA, the SGSN rejects the Routeing Area Update Request with an 
appropriate cause, and may return an Insert Subscriber Data Ack (IMSI, SGSN Area Restricted) message to the 
HLR. If the network supports the MOCN configuration for network sharing, the SGSN may, if the MS is not a 
'Network Sharing Supporting MS', in this case decide to initiate redirection by sending a Reroute Command to 
the RNS, as described in TS 23.251 [24] instead of rejecting the Routeing Area Update Request. If all checks are 
successful, the SGSN constructs an MM context for the MS and returns an Insert Subscriber Data Ack (IMSI) 
message to the HLR. 

NOTE 12: This step is unmodified compared to pre-Rel-8. 

10. The HLR acknowledges the Update Location by sending Update Location Ack (IMSI) to the new SGSN. 
NOTE 13: This step is unmodified compared to pre-Rel-8. 

1 1. If the new SGSN is a 2G-SGSN: The new SGSN validates the MS's presence in the new RA. If due to roaming 
restrictions or access restrictions the MS, is not allowed to be attached in the SGSN, or if subscription checking 
fails, the new SGSN rejects the routeing area update with an appropriate cause. If all checks are successful, the 
new SGSN constructs MM and PDF contexts for the MS. A logical link is established between the new SGSN and 
the MS. The new SGSN responds to the MS with Routeing Area Update Accept (P-TMSI, P-TMSI Signature, 
Receive N-PDU Number). Receive N-PDU Number contains the acknowledgements for each acknowledged- 
mode NSAPI used by the MS, thereby confirming all mobile-originated N-PDUs successfully transferred before 
the start of the update procedure. 

If the new SGSN is a 3G-SGSN: The new SGSN validates the MS's presence in the new RA. If due to roaming 
restrictions or access restrictions the MS is not allowed to be attached in the RA, or if subscription checking 

fails, the SGSN rejects the routeing area update with an appropriate cause. If the network supports the MOCN 
configuration for network sharing, the SGSN may, if the MS is not a 'Network Sharing Supporting MS', in this 
case decide to initiate redirection by sending a Reroute Command to the RNS, as described in TS 23.251 [24] 
instead of rejecting the routeing area update. If all checks are successful, the new SGSN establishes MM context 

for the MS. The new SGSN responds to the MS with Routeing Area Update Accept (P-TMSI, VLR TMSI, P-TMSI 
Signature). 

When receiving the RAU Accept message and there is no ISR indication the UE sets its TIN to "P-TMSI". As 
ISR is not indicated the UE sets in its internal data the update status of the GUTI to "update-needed". 

NOTE 13a: A Gn/Gp SGSN never indicates ISR as it does not support ISR. 

NOTE 14: For the SGSN this step is unmodified compared earlier standards Releases. It is FFS whether and how N- 
PDU numbers are used, e.g. the MME may set the numbers to when creating a context for transferring 
to the SGSN. 

12. If the new SGSN is a 2G-SGSN: The MS acknowledges the new P-TMSI by returning a Routeing Area Update 
Complete (Receive N-PDU Number) message to the SGSN. Receive N-PDU Number contains the 
acknowledgements for each acknowledged-mode NSAPI used by the MS, thereby confirming all mobile- 
terminated N-PDUs successfully transferred before the start of the update procedure. If Receive N-PDU Number 
confirms reception of N-PDUs that were forwarded from the old SGSN, these N-PDUs shall be discarded by the 
new SGSN. LLC and SNDCP in the MS are reset. 

If the new SGSN is a 3G-SGSN: The MS confirms the reallocation of the TMSIs by returning a Routeing Area 
Update Complete message to the SGSN. 

NOTE 15: This step is unmodified compared to pre-Rel-8. It is FFS whether and how N-PDU numbers are used, e.g. 
the UE might ignore any received N-PDU numbers. It is also FFS whether some sequence number 
handling is needed for the case of a 3G-SGSN, or whether continous sequence numbers can be used for 
UTRAN and E-UTRAN. 

13. When the timer started in step 2) expires the old MME or the old S4-SGSN release any RAN and Serving GW 
resources.The old MME/old S4-SGSN deletes the EPS bearer resources by sending Delete Bearer Request 
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(TEID, cause) messages to the Serving GW. Cause indicates to the old Serving GW that the old Serving GW 
shall not initiate a delete procedure towards the PDN GW. The old MME/old S4-SGSN derives from the context 
transfer signalling that the new SGSN is a Gn/Gp SGSN and therefore any old S-GW resources are released by 
the old MME/old S4-SGSN. If the old S-GW has due to ISR a control connection with another CN node (MME 
or SGSN) then the S-GW deletes the bearer resources on the other old CN node by sending Delete Bearer 
Request message(s) to that other old CN node. 

NOTE 16: The new SGSN may initiate RAB establishment after execution of the security functions, or wait until 
completion of the RA update procedure. For the MS, RAB establishment may occur anytime after the 
Routeing Area Update Request is sent. 

In the case of a rejected routeing area update operation, due to regional subscription, roaming restrictions, access 
restrictions (see TS 23.221 [27] and TS 23.008 [28]) or because the SGSN cannot determine the HLR address to 
establish the locating updating dialogue, the new SGSN shall not construct an MM context. A reject shall be returned to 
the MS with an appropriate cause. The MS does not re-attempt a routeing area update to that RA. The RAI value shall 
be deleted when the MS is powered-up. It is FES whether the RAI value being deleted until power up as specified both 
here and in TS 23.060 [7] is correct. 

If the network supports the MOCN configuration for network sharing, the SGSN may, if the MS is not a 'Network 
Sharing Supporting MS', in this case decide to initiate redirection by sending a Reroute Command to the RNS, as 
described in TS 23.251 [24] instead of rejecting the routeing area update. 

If the new SGSN is unable to update the PDF context in one or more GGSNs, the new SGSN shall deactivate the 
corresponding PDF contexts as described in clause "SGSN -initiated PDP Context Deactivation Procedure". This shall 
not cause the SGSN to reject the routeing area update. 

The PDP Contexts shall be sent from old to new SGSN in a prioritized order, i.e. the most important PDP Context first 
in the SGSN Context Response message. (The prioritization method is implementation dependent, but should be based 
on the current activity). 

The new SGSN shall determine the Maximum APN restriction based on the received APN Restriction of each PDP 
context from the GGSN and then store the new Maximum APN restriction value. 

If the new SGSN is unable to support the same number of active PDP contexts as received from old SGSN, the new 
SGSN should use the prioritisation sent by old SGSN as input when deciding which PDP contexts to maintain active 
and which ones to delete. In any case, the new SGSN shall first update all contexts in one or more GGSNs and then 
deactivate the context(s) that it cannot maintain as described in subclause "SGSN -initiated PDP Context Deactivation 
Procedure". This shall not cause the SGSN to reject the routeing area update. 

NOTE 17: In case MS was in PMM-CONNECTED state the PDP Contexts are sent already in the Forward 
Relocation Request message as described in subclause "Serving RNS relocation procedures" of 
TS 23.060 [7]. 

If the routeing area update procedure fails a maximum allowable number of times, or if the SGSN returns a Routeing 
Area Update Reject ( Cause) message, the MS shall enter IDLE state. 

NOTE 18: The CI CAMEL procedure call was omitted intentionally from this procedure since EPS does not support 
CAMEL procedure calls. The other CAMEL procedure calls are unmodified compared to pre-Rel-8. 

The CAMEL procedure calls shall be performed, see referenced procedures in TS 23.078 [29]: 

C2) CAMEL_GPRS_Routeing_Area_Update_Session and CAMEL_PS_Notification. 

They are called in the following order: 

The CAMEL_GPRS_Routeing_Area_Update_Session procedure is called. The procedure returns as result 
"Continue ". 

Then the CAMEL_PS_Notification procedure is called. The procedure returns as result "Continue ". 
C3 ) CAMEL_GFRS_Routeing_Area_Update_Context. 
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D.3.6 Gn/Gp SGSN to MME Tracking Area Update 

The Gn/Gp SGSN to E-UTRAN Tracking Area Update procedure takes place when a UE that is registered with a 
Gn/Gp SGSN selects an E-UTRAN cell. In this case, the UE changes to a Tracking Area that the UE has not yet 
registered with the network. This procedure is initiated by an ECM-IDLE state UE and may also be initiated if the UE is 
in ECM-CONNECTED state. The Pre-Rel-8 SGSN to MME Tracking Area Update procedure is illustrated in 
Figure D.3.6- 1. 

Any steps descriptions that are from TS 23.060 [7] are shown as italic text and remain unmodified. In those step 
descriptions an MS stands for UE, new SGSN for new MME, old SGSN for old Gn/Gp SGSN, GGSN for P-GW, and 
HLRfor HSS. 
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Figure D.3.6-1 : Gn/Gp SGSN to MME Tracking Area Update procedure 

NOTE 1: For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402 [2]. Steps 13 and 15 concern OTP 
based S5/S8. 

1 . The UE selects an E-UTRAN cell of a Tracking Area that is not in the list of TAIs that the UE registered with 
the network or the UE reselects an E-UTRAN cell and is not registered or updated with the MME (e.g. periodic 
TAU timer expired while camping on GERAN or UTRAN) or the UE was in PMM_Connected state (e.g. 
URA_PCH) when it reselects an E-UTRAN cell. 
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2. The UE sends a Tracking Area Update Request (last visited TAI, P-TMSI Signature, old GUTI, UE Network 
Capability, active flag, EPS bearer status, additional GUTI, KSI, NAS sequence number, NAS-MAC) message 
together with an indication of the Selected Network to the eNodeB. 

If the UE's TIN indicates "GUTI" or "RAT-related TMSI" and the UE holds a valid GUTI then the old GUTI 
indicates this vaUd GUTI. If the UE's TIN indicates "P-TMSI" and the UE holds a vaUd P-TMSI and related RAI 
then these two elements are indicated as the old GUTI. Mapping a P-TMSI and an RAI to a GUTI is specified in 
Annex H. 

If the UE holds a valid GUTI then the UE indicates the GUTI as additional GUTI, regardless whether the old 
GUTI also indicates this GUTI or a GUTI mapped from a P-TMSI. 

The routing parameter that is signalled in the RRC signalling to the eNB for routing to the MME is derived from 
the identifier that is signalled as the old GUTI according to the rules above. For a combined MME/SGSN the 
eNB is configured to route the MME-code(s) of this combined node to the same combined node. This eNB is 
also configured to route MME-code(s) of GUTIs that are generated by the UE's mapping of the P-TMSIs 
allocated by the combined node. Such an eNB configuration may also be used for separate nodes to avoid 
changing nodes in the pool caused by inter RAT mobility. 

NOTE 2: In the scenario of this flow the UE's TIN indicates "P-TMSI" and therefore the UE indicates a P-TMSI as 
the old GUTI. 

The last visited TAI is included if the UE has any in order to help the MME to produce a good list of TAIs for 
any subsequent TAU Accept message. Selected Network indicates the network that is selected. Active flag is a 
request by UE to activate the radio and SI bearers for all the active EPS Bearers by the TAU procedure. The 
EPS bearer status indicates each EPS bearer that is active within the UE. The UE's ISR capability is included in 
the UE Network Capability element. 

3. The eNodeB derives the MME from the old GUMMEI (contained within the old GUTI) and the indicated 
Selected Network. If that GUMMEI is not associated with the eNodeB, or the GUMMEI is not available, the 
eNodeB selects the MME as described in clause 4.3.8.3 on "MME Selection Function". The eNodeB forwards 
the TAU Request message together with the ECGI of the cell from where it received the message and with the 
Selected Network to the MME. 

4. The new MME sends SGSN Context Request (old RAI, TLLI, old P-TMSI Signature, New SGSN Address) to 
the old SGSN to get the MM and PDP contexts for the UE. 

The new MME shall support functionality for Intra Domain Connection of RAN Nodes to Multiple CN Nodes, 
i.e. the MME derives the old SGSN from the old RAI and the old P-TMSI (or TLLI). 

5. In case the old SGSN is a 2G-SGSN: The old 2G-SGSN validates the old P TMSI Signature and responds with 
an appropriate error cause if it does not match the value stored in the old 2G SGSN. This should initiate the 
security functions in the new SGSN. If the security functions authenticate the MS correctly, the new SGSN shall 
send an SGSN Context Request (old RAI, old PTMSI, MS Validated, New SGSN Address) message to the old 
SGSN MS Validated indicates that the new SGSN has authenticated the MS. If the old P-TMSI Signature was 
valid or if the new SGSN indicates that it has authenticated the MS, the old SGSN stops assigning SNDCP 
N-PDU numbers to downlink N-PDUs received, and responds with SGSN Context Response (MM Context, PDP 
Contexts). If the MS is not known in the old SGSN, the old SGSN responds with an appropriate error cause. The 
old SGSN stores New SGSN Address, to allow the old SGSN to forward data packets to the new SGSN. Each 
PDP Context includes the SNDCP Send N-PDU Number for the next downlink N-PDU to be sent in 
acknowledged mode to the MS, the SNDCP Receive N-PDU Number for the next uplink N-PDU to be received in 
acknowledged mode from the MS, the GTP sequence number for the next downlink N-PDU to be sent to the MS 
and the GTP sequence number for the next uplink N-PDU to be tunnelled to the GGSN The old SGSN starts a 
timer and stops the transmission of N-PDUs to the MS. The new SGSN shall ignore the MS Network Capability 
contained in MM Context of SGSN Context Response only when it has previously received an MS Network 
Capability in the Routeing Area Request. 

In case the old SGSN is a 3G-SGSN: The old 3G-SGSN validates the old P TMSI Signature and responds with 
an appropriate error cause if it does not match the value stored in the old SGSN. This should initiate the security 
functions in the new SGSN. If the security functions authenticate the MS correctly, the new SGSN shall send an 
SGSN Context Request (IMSI, old RAI, MS Validated) message to the old 3G-SGSN MS Validated indicates that 
the new SGSN has authenticated the MS. If the old P TMSI Signature was valid or if the new SGSN indicates that 
it has authenticated the MS, the old SGSN starts a timer. If the MS is not known in the old SGSN, the old 3G- 
SGSN responds with an appropriate error cause. 
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The old 3G SGSN responds with an SGSN Context Response (MM Context, PDF Contexts) message. For each 
FDF context the old 3G SGSN shall include the GTF sequence number for the next uplink GTF FDU to be 
tunnelled to the GGSN and the next downlink GTF sequence number for the next FDU to be sent to the MS. Each 
FDF Context also includes the FDCF sequence numbers ifFDCF sequence numbers are received from the old 
SRNS. The new 3G-SGSN shall ignore the MS Network Capability contained in MM Context of SGSN Context 
Response only when it has previously received an MS Network Capability in the Routeing Area Request. The 
GTF sequence numbers received from the old 3G-SGSN are only relevant if delivery order is required for the 
FDF context ( QoS profile). 

Editor note: It is FFS whether the NRI is also dupHcated by the UE to be put in a separate MME field, it is 
expected that the UE will send NRI in the appropriate field depending on current RAT. 

NOTE 3: In this step, the new "SGSN" shall be understood to be a new "MME" and the old SGSN stores new 

SGSN Address, to allow the old SGSN to forward data packets to the new "S-GW or eNodeB". This step 
describes both the 2G and 3G SGSN variants due to combining the 2G or 3G SGSN to MME TAU into a 
single procedure. 

NOTE 4: For the old SGSN, this step is unmodified compared to pre-Rel-8. The MME (called new SGSN in above 
description) must provide SGSN functionality which includes mapping PDP contexts to EPS bearer 
information. 

6. Security functions may be executed. Procedures are defined in clause 5.3.10 on Security Function. If the SGSN 
Context Response message from the old SGSN did not include IMEISV, the MME shall retrieve the ME Identity 
(the IMEISV) from the UE. 

7. The new MME sends an SGSN Context Acknowledge message to the old SGSN. This informs the old SGSN that 
the new SGSN is ready to receive data packets belonging to the activated FDF contexts. The old SGSN marks in 
its context that the MSC/VLR association and the information in the GGSNs and the HLR are invalid. This 
triggers the MSCA^LR, the GGSNs, and the HLR to be updated if the MS initiates a routeing area update 
procedure back to the old SGSN before completing the ongoing routeing area update procedure. 

If the security functions do not authenticate the UE correctly, then the Tracking area update shall be rejected, and 
the new MME shall send a reject indication to the old SGSN. The old SGSN shall continue as if the SGSN 
Context Request was never received. 

NOTE 5: in the italic text of this step, new "SGSN" shall be understood as to be a new "MME". 

The MME needs to map PDP contexts received from pre-Rel-8 SGSN into EPS bearer information. The 
GGSN address(es) and TEIDs map to the PDN GW address(es) and TEIDs respectively. Other aspects of 
this mapping is FFS. 

NOTE 6: The SGSN operation is unmodified compared to pre-Rel-8. The handling within the MME may need 
further alignment with the Rel-8 inter RAT RAU, e.g. FFS whether this informs the old SGSN that the 
new MME is ready to receive data packets belonging to the activated PDP contexts and how to perform 
any data forwarding from BSS or SGSN to the eNodeB. 

NOTE 7: The Gn signalling between the new MME and the old Gn/Gp SGSN has no capabilities to indicate ISR. 

Editor's note: It is FFS when eNodeB resources are allocated and how transfer of data with the eNodeB will take 
place 

If there is no PDP context suitable for default bearer or no PDP context at all, the MME rejects the TAU 
Request. 

Editor's note: It is FFS whether a TAU Accept can be done instead with an indication that default bearer is not 
established. 

8. The old SGSN or the old RNC forward data to the eNodeB (FFS). 

9. The new MME adopts the bearer contexts received from the SGSN as the UE's EPS bearer contexts to be 
maintained by the new MME. The new MME maps the PDP contexts to the EPS bearers 1-to-l and maps the 
pre-Rel-8 QoS parameter values of a PDP context to the EPS QoS parameter values of an EPS bearer as defined 
in Annex E. The MME establishes the EPS bearer(s) in the indicated order. The MME deactivates the EPS 
bearers which cannot be established. 
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The MME verifies the EPS bearer status received from the UE with the bearer contexts received from the old 
SGSN and releases any network resources related to EPS bearers that are not active in the UE. If the UE has no 
PDP context, the MME rejects the TAU Request. 

The new MME selects a Serving GW and sends an Create Bearer Request (IMSI, MME Context ID, PDN GW 
address and TEID, QoS Negotiated converted FES, serving network identity, ME Identity, CGI/SAI, RAT type, 
ECGI/SAI/RAI change support indication, NRS (received from the SGSN), ISR) message to the Serving GW. 
The MME shall send the serving network identity to the Serving GW. The information element ISR indicates 
that ISR is not established. 

10. The Serving GW creates contexts and informs the PDN GW(s) about the change of the RAT type. The Serving 
GW sends an Update Bearer Request (Serving GW Address and TEID, RAT type, ME Identity) message to the 
PDN GW(s) concerned. 

1 1 . If dynamic PCC is deployed, and RAT type information needs to be conveyed from the PDN GW to the PCRF, 
then the PDN GW shall send RAT type information to the PCRF by performing an IP-CAN Session 
Establishment procedure as defined in TS 23.203 [6]. 

NOTE 8: The PDN GW does not need to wait for the PCRF response, but continues in the next step. If the PCRF 
response leads to an EPS bearer modification the PDN GW should initiate a bearer update procedure. 

12. The PDN GW updates its context field and returns an Update Bearer Response (PDN GW address and TEID, 
MSISDN) message to the Serving GW. The MSISDN is included if the PDN GW has it stored in its UE context. 

13. The Serving GW updates its context and returns an Create Bearer Response (MME Context ID, Serving GW 
address and TEID for user plane, PDN GW address and TEID, Serving GW Context ID) message to the new 
MME. 

14. To ensure the release of all UE resources in the Gn/Gp SGSN the new MME informs the HSS of the change of 
the serving core network node by sending an Update Location (MME Address, IMSI, ME Identity, Update Type) 
message to the HSS. The ME Identity is included if the SGSN Context Response did not contain the IMEISV. 
Because of interoperation with an Gn/Gp SGSN, which the new MME identifies from the Context Response 
signalling, the Update Type is set to "MME only registration". 

15. If the MME changes, then the HSS cancels any old MME as the Update Type indicates "MME only 
registration". The HSS sends a Cancel Location (IMSI, Cancellation type) message to the old MME, with a 
Cancellation Type set to Update Procedure. 

16. The old MME removes the MM context. 

The old MME releases any local bearer resources and it deletes the EPS bearer resources by sending Delete 
Bearer Request (Cause, TEID) messages to the Serving GW. Cause indicates that the S-GW shall not initiate a 
delete procedure towards the PDN GW. If ISR is active on the S-GW then the S-GW deletes the bearer resources 
on the other old CN node by sending Delete Bearer Request message(s) to that CN node. 

The old MME acknowledges with a Cancel Location Ack (IMSI) message. 

17. The HSS cancels any old SGSN node as the Update Type indicates "MME only registration". The HSS sends a 
Cancel Location (IMSI, Cancellation Type) message to the old SGSN. The old SGSN removes the contexts. 

If the timer started in step 5 is not running, the old SGSN removes the MM context. Otherwise, the contexts are 
removed when the timer expires. It also ensures that the MM context is kept in the old SGSN for the case the UE 
initiates another TAU procedure before completing the ongoing TAU procedure to the new MME. 

18. receipt of Cancel Location, if the MS is PMM CONNECTED in the old SGSN, the old SGSN sends an lu 
Release Command message to the old SRNC 

19. When the data-forwarding timer has expired, the SRNS responds with an lu Release Complete message. 

20. The old SGSN acknowledges with a Cancel Location Ack (IMSI) message. 

21. The HSS sends Insert Subscriber Data (IMSI, Subscription Data) to the new MME. 

22. The new MME validates the UE's presence in the (new) TA. If due to regional subscription restrictions or access 
restrictions the UE is not allowed to be attached in the TA, the MME rejects the Tracking Area Update Request 
with an appropriate cause, and may return an Insert Subscriber Data Ack (IMSI, MME Area Restricted) message 
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to the HSS. If all checks are successful, the MME constructs an MM context for the UE and returns an Insert 
Subscriber Data Ack (IMSI) message to the HSS. 

23. The HLR acknowledges the Update Location by sending Update Location Ack (IMSI) to the new MME. If the 
Update Location is rejected by the HSS, the MME rejects the TAU Request from the UE with an appropriate 
cause sent in the TAU Reject message to the UE. 

24. The new MME responds to the UE with a Tracking Area Update Accept (GUTI, TAI-list, EPS bearer status, 
KSI, NAS sequence number, NAS-MAC, NAS security algorithm)) message. Restriction list shall be sent to 
eNodeB as eNodeB handles the roaming restrictions and access restrictions in the Intra E-UTRAN case. 

If the "active flag" is set in the TAU Request message the user plane setup procedure can be activated in 
conjunction with the TAU Accept message. The procedure is described in detail in TS 36.300 [5]. The messages 
sequence should be the same as for the UE triggered Service Request procedure specified in clause 5.3.4.1 from 
the step when MME establishes the bearer(s). If the active flag is set the MME may provide the eNodeB with 
Handover Restriction List. Handover Restriction List is described in clause 4.3.5.7 "Mobility Restrictions". The 
EPS bearer status indicates the active bearers in the network. The UE removes any internal resources related to 
bearers not marked active in the received EPS bearer status. 

When receiving the TAU Accept message and there is no ISR indication the UE sets its TIN to "GUTI". When 
ISR is not indicated the UE clears any internal ISR status by setting its internal update status for the P-TMSI to 
"update-needed". 

NOTE 8: In the case of interoperation with Gn/Gp SGSNs ISR is never indicated by the MME as the SGSN does 
not support ISR, which the new MME recognises from Gn interface signalling that does not support ISR 
indications. 

25. If the GUTI was included in the TAU Accept message, the UE acknowledges the message by returning a 
Tracking Area Update Complete message to the MME. 

NOTE 9: The new MME may initiate RAB establishment after execution of the security functions (step 5), or wait 
until completion of the TA update procedure. For the UE, RAB establishment may occur anytime after 
the TA update request is sent (step 2). 

In the case of a rejected tracking area update operation, due to regional subscription, roaming restrictions, or access 
restrictions (see TS 23.221 [27] and TS 23.008 [28]) the new MME shall not construct a bearer context. A reject shall 
be returned to the UE with an appropriate cause and the S 1 connection shall be released. Upon return to idle, the UE 
shall act according to TS 23.122 [10]. 

If the new MME is unable to update the bearer context in one or more P-GWs, the new MME shall deactivate the 
corresponding bearer contexts as described in subclause "MME Initiated Dedicated Bearer Deactivation Procedure". 
This shall not cause the MME to reject the tracking area update. 

The PDP Contexts shall be sent from old SGSN to new SGSN (MME) in a prioritized order, i.e. the most important PDP 
Context first in the SGSN Context Response message. (The prioritization method is implementation dependent, but 
should be based on the current activity). 

The new MME shall determine the Maximum APN restriction based on the received APN Restriction of each bearer 
context from the P-GW and then store the new Maximum APN restriction value. 

If the new MME is unable to support the same number of active bearer contexts as received from old SGSN, the new 
MME should use the prioritisation sent by old SGSN as input when deciding which bearer contexts to maintain active 
and which ones to delete. In any case, the new MME shall first update all contexts in one or more P-GWs and then 
deactivate the context(s) that it cannot maintain as described in subclause "MME Initiated Dedicated Bearer 
Deactivation Procedure". This shall not cause the MME to reject the tracking area update. 

NOTE 10: In case MS (UE) was in PMM-CONNECTED state the PDP Contexts are sent already in the Forward 
Relocation Request message as described in subclause "Serving RNS relocation procedures" of 
TS 23.060 [7]. 

If the tracking area update procedure fails a maximum allowable number of times, or if the MME returns a Tracking 
Area Update Reject (Cause) message, the UE shall enter EMM DEREGISTERED state. 

If the Update Location Ack message indicates a reject, this should be indicated to the UE, and the UE shall not access 
non-PS services until a successful location update is performed. 
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The CAMEL procedure calls shall be performed, see referenced procedures in TS 23.078 [29]: 

CI ) CAMEL_GPRS_PDP_Context_Disconnection, CAMEL_GPRS_Detach and CAMEL_PS_Notification. 

They are called in the following order: 

- The CAMEL_GPRS_PDP_Context_Disconnection procedure is called several times: once per PDP context. 
The procedure returns as result "Continue". 

Then the CAMEL_GPRS_Detach procedure is called once. The procedure returns as result "Continue". 
Then the CAMEL_PS_Notification procedure is called once. The procedure returns as result "Continue". 
NOTE ll:This CAMEL handling is unmodified compared to pre-Rel-8. 

NOTE 12: CAMEL procedure calls C2 and C3 were omitted intentionally from this procedure since EPS does not 
support CAMEL procedure calls. 
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Annex E (normative): 

Mapping between EPS and pre-Rel-8 QoS parameters 

This annex specifies how the QoS parameter values of an EPS bearer (E-UTRAN access to the EPS) should be mapped 
to/from the pre-Rel-8 QoS parameter values of a PDP context (UTRAN/GERAN access to the EPS) before a procedure 
is triggered that executes a handover between E-UTRAN and UTRAN/GERAN. 

The following mapping rules hold: 

- There is a one-to-one mapping between an EPS bearer and a PDP context. 

Editor's Note: The handling of this principle in case of "dual stack IPv4/IPv6 bearers" is ESS. 

- The EPS bearer parameters ARP is mapped one-to-one to/from the pre-Rel-8 bearer parameter ARP. 

Editor's Note: Note that in GPRS pre-Rel-8 the same UE/PDN connection, the system does not expect to have two or 
more PDP contexts with different ARP values. This is different in EPS. It is FES whether this causes 
conflict / errors or whether a specific mapping rule for ARP is needed. 

- The EPS bearer parameters GBR and MBR of a GBR EPS bearer are mapped one-to-one to/from the pre-Rel-8 
bearer parameters GBR and MBR of a PDP context associated with Traffic class 'conversational' or 'streaming'. 

Editor's Note: The details of the mapping of GBR, and MBR between GBR EPS bearers and conversational / 

streaming PDP contexts should be captured in stage 3 specs. Once done this editor's note will be replaced 
with a corresponding reference. 

- At handover from E-UTRAN to UTRAN/GERAN the pre-Rel-8 bearer parameter MBR of PDP contexts 
associated with Traffic Class 'interactive' or 'background' is set based on MME operator policy. 

NOTE 1 : In order to apply the concept of AMBR in UTRAN/GERAN, one such policy may be to set the sum of 
those MBRs to not exceed the value of the EPS bearer parameter AMBR. 

NOTE 2: In order to ensure that the MBR of PDP contexts associated with Traffic Class 'interactive' or 
'background' are restored to their previous values when handing over again from E-UTRAN to 
UTRAN/GERAN, one such policy may be to have an MME store at handover from UTRAN/GERAN to 
E-UTRAN the pre-Rel-8 bearer parameter MBR of PDP contexts associated with Traffic Class 
'interactive' or 'background'. 

- At handover from UTRAN/GERAN to E-UTRAN the AMBR from the EPS subscribed QoS profile for the 
corresponding APN shall take precedence. In case of handover from a pre-Rel8 SGSN and if the MME has no 
subscribed AMBR value for the UE, the MME provides a local AMBR to the eNodeB, Serving GW and 
PDNGW until MME gets the EPS subscribed AMBR. This local AMBR may be for example based on the 
summing up of pre-Rel-8 bearer parameter MBR of all the interactive / background PDP contexts or on internal 
configuration. When the MME gets the subscribed AMBR value from the HSS, it compares it with the local 
AMBR and if the two AMBRs are different, the MME initiates HSS Initiated Subscribed QoS Modification 
procedure to notify the subscribed AMBR to the eNodeB, Serving GW and PDNGW. 

Editor's note: Handling of AMBR in case of handover from Rel8 SGSN is FES. 

- A standardized value of the EPS bearer parameter QCI is mapped one-to-one to/from values of the pre-Rel-8 
parameters Traffic Class, Traffic Handling Priority, Signalling Indication, and Source Statistics Descriptor as 
shown in Table E-1. 

- At handover from E-UTRAN to UTRAN/GERAN the setting of the values of the pre-Rel-8 parameters Transfer 
Delay and SDU Error Ratio should be derived from the corresponding QCI's Packet Delay Budget and Packet 
Loss Rate, respectively. At handover from UTRAN/GERAN to E-UTRAN the values of the pre-Rel-8 
parameters Transfer Delay and SDU Error Ratio should be ignored. 

- The setting of the values of all other pre-Rel-8 QoS is based on operator policy pre-configured in the MME. 
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Table E-1: Mapping between standardized QCIs and pre-Rel-8 QoS parameter values 





Traffic 
Class 


Traffic 


Signaling 


Source 


QCI 


Handling 


Indication 


Statistics 




Priority 




Descriptor 


1 


Conversational 


N/A 


N/A 


Speech 


2 


Conversational 


N/A 


N/A 


Unknown 


FFS 


Streaming 


N/A 


N/A 


Speech 


3 


Streaming 


N/A 


N/A 


Unknown 


5 


Interactive 


1 


Yes 


N/A 


7 


Interactive 


1 


No 


N/A 


6 


Interactive 


2 


No 


N/A 


8 


Interactive 


3 


No 


N/A 


9 


Background 


N/A 


N/A 


N/A 



Editor's Note: The mapping of QCI 4 is FFS. 
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Annex F (normative): 

Dedicated bearer activation in combination with the default 
bearer activation at Attach and UE requested PDN 
connectivity procedures 

It shall be possible for the PDN GW to initiate the activation of dedicated bearers (as specified in clause 5.4.1) as part of 
the attach procedure (as specified in clause 5.3.2.1) or as part of the UE requested PDN connectivity procedure (as 
specified in clause 5.10.2) over EUTRAN. However the result of the dedicated bearer activation procedure shall be 
logically separate from the Attach procedure, meaning that the result of the Attach procedure is not dependent on 
whether the Dedicated bearer activation procedure succeeds or not. On the other hand, the dedicated bearer activation 
may only be regarded as successful if the Attach procedure completes successfully. 

The messages of the Dedicated bearer activation can be sent together with the messages of the Attach procedure or of 
the UE requested PDN connectivity procedure (i.e. Attach accept or PDN Connectivity Accept), as shown in the Figure 
and explanation below. 

Editor's note: It is considered a stage 3 question whether the Create Default Bearer Response message is 

piggybacked with the Create Dedicated Bearer Request on S5/S8 and SI 1, or alternatively other ways are 
used to tie those messages together such that the MME can recognize that a Create Default Bearer 
Response message is combined with a Create Dedicated Bearer Request message. However, it is 
necessary to ensure that the UE sees that the Dedicated Bearers are established at Attach in order to 
prevent the UE requesting establishment of the (the same) dedicated resources immediately following the 
Attach Accept message. 

On the S 1 and Uu interfaces the messages for the default bearer activation at Attach and UE requested PDN 
connectivity procedures and for the Dedicated Bearer Activation procedure are combined into a single message. If the 
MME has sent an Attach Accept message towards the eNodeB, and then the MME receives a Create Dedicated Bearer 
Request before the MME receives the Attach Complete message, the MME shall wait for the Attach procedure to 
complete before the MME continues with Dedicated Bearer Activation procedure. 

It shall be possible that multiple dedicated bearers can simultaneously be activated in the signaling flow shown below. 
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Figure F.1 : Dedicated bearer activation in combination witli tlie default bearer activation at attach or 

UE requested PDN connectivity 



NOTE 1: Parameters related to dedicated bearer activation are written in italics. 

Figure F. 1 describes the activation of dedicated bearer(s) in combination with the default bearer activation either as part 
of the Attach procedure (with specific steps la, 7a, 10a) or as part of the UE requested PDN connectivity procedure 
(with specific steps lb, 7b, 10b). The following steps below require special attention: 

5. (On the P-GW-S-GW interface) Create Default Bearer Response message of the Attach procedure or 

UE-requested PDN connectivity procedure is combined with Create Dedicated Bearer Request message of the 
Dedicated Bearer Activation Procedure 
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6. (On the S-GW-MME interface) Create Default Bearer Response message of the Attach procedure or 

UE-requested PDN connectivity procedure is combined with the Create Dedicated Bearer Request message of 
the Dedicated Bearer Activation Procedure 

7a. In case of Attach procedure: If the MME receives a Create Default Bearer Response message combined with a 
Create Dedicated Bearer Request message, the MME shall send the Sl-AP Initial Context Setup Request 
message to the eNodeB, including the NAS parts for both the Attach Accept message of the Attach procedure 
and the Bearer Setup Request of the Bearer Activation Procedure. 

NOTE 2: The MME shall not send a Bearer Setup Request message of a new Dedicated Bearer Activation 
procedure to the eNodeB before sending the Attach Accept message of the Attach procedure to the 
eNodeB. If the MME has already sent the Attach Accept message of the Attach procedure to the eNodeB, 
the MME shall wait for the Attach Complete message to arrive before sending a separate Bearer Setup 
Request of a Dedicated Bearer Activation procedure. 

7b. In case of UE requested PDN connectivity procedure: If the MME receives a Create Default Bearer Response 
message combined with a Create Dedicated Bearer Request message, the MME shall send the Sl-AP Bearer 
Setup Request message to the eNodeB, including the NAS parts for both the PDN Connectivity Accept message 
and the Bearer Setup Request of the Bearer Activation Procedure. 

8-9. The radio bearer establishment of the default and dedicated bearer(s) is performed in the same RRC message. 

10a. In case of Attach procedure: The eNodeB sends the Sl-AP Initial Context Setup Response message to the 
MME, which contains the NAS parts for both the Attach Complete message of the Attach procedure and the 
Bearer Setup Response of the Dedicated Bearer Activation Procedure. 

10b. In case of UE requested PDN connectivity procedure: The eNodeB sends the Sl-AP Bearer Setup Response 
message to the MME, which contains the NAS parts for the Bearer Setup Response of the Dedicated Bearer 
Activation Procedure. 

1 1. The Update Bearer Request message of the Attach procedure or UE requested PDN connectivity procedure is 
combined with the Create Dedicated Bearer Response message of the Dedicated Bearer Activation Procedure. 
After that, the Serving GW continues with sending a Create Dedicated Bearer Response message to the PDN 
GW. 
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Annex G: 
Void 
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Annex H (normative): 

Mapping between temporary and area identities 

This annex provides information on the mapping of these identities, e.g. for the construction of the Routeing Area 
Update Request message in GERAN/UTRAN or Tracking Area Update Request message in E-UTRAN. 

Clause 5.2 of this specification contains information on the EPS Identities. 

In E-UTRAN, 

<GUTI> = <GUMMEI><M-TMSI>, 

where <GUMMEI> = <MCC><MNC><MME Identifier> 

and <MME Identifier> = <MME Group IDxMME Code> 
MCC and MNC have the same field size as in pre release 8 3GPP systems. 
M-TMSI is aof 32 bits length. 
MME Code is of 8 bits length. 
MME Group ID is of 16 bits length. 
In GERAN and UTRAN, 

<RAI> = <MCC><MNC><LAC><RAC> 

<P-TMSI> Includes mapped NRI 

P-TMSI is of 32 bits length where the two topmost bits are reserved and always set to 1 1. This is needed since the 
GERAN representation of P-TMSI, on the form TLLI, impose this restriction. Hence, for a UE which may handover to 
GERAN/UTRAN (based on subscription and UE capabilities), the corresponding bits in the M-TMSI are set to 1 1. 

The NRI field is of variable length and is mapped into the P-TMSI starting at bit 23 and down to bit 14. The most 
significant bit of the NRI is located at bit 23 of the P-TMSI regardless of the configured length of the NRI. 

The P-TMSI and NRI are defined by TS 23.003 [9]. 

In case of a combined MME-SGSN node, the NRI of the SGSN part and the MME code of the MME part refer to the 
same combined node. RAN configuration allows NAS messages on GERAN/UTRAN and E-UTRAN to be routed to 
the same combined node. The same or different values of NRI and MME code may be used for a combined node. 

The mapping of the GUTI is done to the combination of RAI of GERAN / UTRAN and the P-TMSI: 

E-UTRAN <MCC> maps to GERAN/UTRAN <MCC> 

E-UTRAN <MNC> maps to GERAN/UTRAN <MNC> 

E-UTRAN <MME Group ID> maps to GERAN/UTRAN <LAC> 

E-UTRAN <S-TMSI> maps as follows: 

- E-UTRAN <MME Code> maps to GERAN/UTRAN <RAC> and is also copied into the 8 most significant bits 
of the NRI field within the P-TMSI; 

- 22 bits of the E-UTRAN <M-TMSI> is mapped into the remaining 22 bits of the GERAN/UTRAN <P-TMSI>; 
and 

- the remaining 8 bits of the E-UTRAN <M-TMSI> are copied into 8 bits of the <P-TMSI signature> field. 

For UTRAN, the 10-bit long NRI bits are masked out from the P-TMSI and also suppHed to the RAN node as IDNNS 
(Intra Domain NAS Node Selector). 
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The mapping of P-TMSI (TLLI) and RAI in GERANAJTRAN to GUTI in E-UTRAN is performed as follows. 

GERANAJTRAN <MCC> maps to E-UTRAN <MCC> 

GERANAJTRAN <MNC> maps to E-UTRAN <MNC> 

GERANAJTRAN <LAC> maps to E-UTRAN <MME Group ID> 

GERANAJTRAN <RAC> maps to 8 bits of the M-TMSI 
The 8 most significant bits of GERANAJTRAN <NRI> maps to the MME code 

GERANAJTRAN <P-TMSI or TLLI> excluding the 8 most significant bits at the NRI position maps to the remaining 
bits of the M-TMSI. 

The values of <LAC> and <MME group id> shall be disjoint so that they can be differentiated. It is recommended that 
the most significant bit of the <LAC> shall be set to zero; and the most significant bit of <MME group id> shall be set 
to one. 

During RRC connection establishment for Attach Request and Tracking Area Update Request over E-UTRAN, the full 
PLMN id is signalled to the eNodeB in order to enable routing to the appropriate MME. 
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Annex I (informative): 

Guidance for contributors to this specification 

The following guidance is provided for drafting figures for this specification TS 23.401 that contain specific steps 
which are different in TS 23.402 [2] due to the PMIP-based S5/S8 interface: 

- Message flows to this specification will contain the complete procedures applicable for GTP-based S5/S8 only. 

- In this specification, section(s) of a message flow that is different for PMIP-based S5/S8 interface are shown 
surrounded by shaded box indexed by an upper-case letter in ascending order, e.g. "A", "B", "C", etc. 

For example, at the bottom of the flow, the following text should be included: 

"NOTE: Procedure steps (A) and (B) for an PMIP-based S5/S8 interface are defined in TS 23.402 [2]." 

- Further guidance for drafting procedures for TS 23.402 [2] can be found in that specification itself. 
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Annex J (informative): 
High Level ISR flows 

The high level ISR flows show only the handling of the TMSIs for simplification. Related RAs/TAs are always 
signalled with the TMSIs when defined by the detailed procedures. Also other lEs are not shown when not necessary 
for the high level description. 

This Annex will be removed once the ISR functionality is captured by the detailed procedures. 
ISR follows following principles: 

- UE registers to the MME and SGSN separately; 

- MME and SGSN register to the HSS and the HSS maintain two PS registrations; 

- UE needs to be informed by the CN nodes (SGSN and MME) if the ISR functionality is activated or deactivated 
for that UE; 

- There is no "signahng free reselection" of an E-UTRAN cell by a UE in URA_PCH state (e.g. URA_PCH is 
treated as active mode by the UE/EPC when moving to E-UTRAN); 

- When ISR is activated for 2G and/or 3G, Idle Mode UP Termination is in S-GW for that RAT; 

- The Serving GW needs to be informed if the ISR functionality is activated or deactivated for a UE; 

- Two periodic update timers, running separately in the UE for updating SGSN and MME separately: 

- Functionality is needed in SGSN and MME to avoid the deletion of the PDP context/EPS Bearers because of 
nussing periodic updates. 

- HSS keeps double registration for MME and R8 SGSN. 

- When a UE moves from a Pre-8 SGSN to MME, the SGSN registration at HSS is cancelled. 

- When ISR is activated, the CN entity stores the control plane address of the other RAT CN entity. 

- When an ISR deactivated UE (including URA_PCH UE) changes the RAT, the UE initiates update with Update 
Type "ISR synch". 

The ISR activated UE will set internally "ISR synch need" in case there is any bearer change in the currently 
used RAT. When the ISR activated UE with "ISR synch need" changes to another RAT, it will initiate update 
with Update Type "ISR synch". After the update with Update Type as "ISR synch", "ISR synch need" is unset in 
UE. 

- When an ISR activated UE moves from URA_PCH into E-UTRAN, it initiates update. If there is no "ISR synch 
need", the Update Type is "URA_PCH handling"; else the Update Type is "ISR synch". 

- In other cases (i.e. no ISR synch and no URA_PCH handling), the UE initiates update with Update Type as "RA 
updating" or "TA updating" when moving out of the registered area; and the UE initiates update with Update 
Type as "periodic updating" when the current RAT periodic timer expires or when the UE changes the RAT and 
it memorises that the current RAT periodic timer expired when the UE camped on the other RAT. 
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